* Git in next is broken
From: Nicolas Pitre @ 2009-11-12 20:36 UTC (permalink / raw)
To: git; +Cc: Julian Phillips
Simply issuing a "git fetch" in my copy of git.git makes glibc complain
with this:
*** glibc detected *** git: corrupted double-linked list: 0x0000000000974180 ***
The gdb backtrace is:
(gdb) bt
#0 0x0000003c76632f05 in raise () from /lib64/libc.so.6
#1 0x0000003c76634a73 in abort () from /lib64/libc.so.6
#2 0x0000003c76672438 in __libc_message () from /lib64/libc.so.6
#3 0x0000003c76677ec8 in malloc_printerr () from /lib64/libc.so.6
#4 0x0000003c7667a23e in _int_free () from /lib64/libc.so.6
#5 0x0000003c7667a486 in free () from /lib64/libc.so.6
#6 0x0000000000493f3f in ref_remove_duplicates (ref_map=0x7562b0)
at remote.c:756
#7 0x0000000000424afc in get_ref_map () at builtin-fetch.c:165
#8 do_fetch () at builtin-fetch.c:644
#9 cmd_fetch (argc=<value optimized out>, argv=0x7fffffffe6a0,
prefix=<value optimized out>) at builtin-fetch.c:754
#10 0x0000000000403d83 in run_builtin () at git.c:251
#11 handle_internal_command (argc=1, argv=0x7fffffffe6a0) at git.c:396
#12 0x0000000000403f2d in run_argv () at git.c:438
#13 main (argc=1, argv=0x7fffffffe6a0) at git.c:509
Bisection reveals the following culprit:
commit 73cf0822b2a4ffa7ad559d1f0772e39718fc7776
Author: Julian Phillips <julian@quantumfyre.co.uk>
Date: Sun Oct 25 21:28:11 2009 +0000
remote: Make ref_remove_duplicates faster for large numbers of refs
The ref_remove_duplicates function was very slow at dealing with very
large numbers of refs. This is because it was using a linear search
through all remaining refs to find any duplicates of the current ref.
Rewriting it to use a string list to keep track of which refs have
already been seen and removing duplicates when they are found is much
more efficient.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reverting that commit from next does indeed fix the problem.
Note that this problem doesn't show up with all repositoryes.
Nicolas
^ permalink raw reply
* Re: [PATCHv3] Add branch management for releases to gitworkflows
From: Raman Gupta @ 2009-11-12 20:30 UTC (permalink / raw)
To: skillzero; +Cc: git, trast, gitster
In-Reply-To: <2729632a0911121208r1f51cf9ewb0bc23e757275f30@mail.gmail.com>
skillzero@gmail.com wrote:
>> +.Update maint to new release
>> +[caption="Recipe: "]
>> +=====================================
>> +* `git branch -f next master`
>> +* `git merge ai/topic_in_next1`
>> +* `git merge ai/topic_in_next2`
>
> Shouldn't that be something like "Update next to new release" instead
> of "maint"?
Oops. I changed the caption to "Rewind and rebuild next".
> Should it also have 'git checkout next' after the branch command so
> it's on next before merging?
Right, fixed also.
Thanks,
Raman
^ permalink raw reply
* Tracked file suddenly disappeared just prior to commit.
From: Kaz Kylheku @ 2009-11-12 20:10 UTC (permalink / raw)
To: git
I am running git 1.6.5rc2 on a somewhat dated system (RH EL 4, i686).
The working copy is on an NFS mount from ``Big File Server used by Lots of
People''.
I ran ``git diff > diffs'' to capture some work. I was then editing the
ChangeLog file, making comments based on the diffs. I had modified two files:
a C source file and its corresponding header. I spent maybe ten minutes doing
up the ChangeLog entry for these changes.
Then I quit the editor and ran ``git commit -a''.
In the commit comment, I saw git's shocking report that the C file had been
deleted! Apparently, I am about to commit a deletion of the file I hacked on!
So I emptied the comment to abort the commit. I listed the
directory and surely enough, the file was gone.
For a split second I thought that I lost the changes, but then I realized I had
the diff in the "diffs" file, so I recovered with a ``git checkout'', followed
by a patch. Phew!
How could that have happened? I haven't seen issues like this with the
NFS server at all. The file hadn't been recently created, and it hadn't been
touched for 12 hours since I made the changes.
Could another user have deleted the file as a prank? In this insecure
environment, you can impersonate another user to get around
directory permissions. It can't be logically ruled out that someone
was messing with my working copy.
I checked my bash history as well as the command history in Vim, but could find
no traces of any accidental delete command, or any command which might lead to
deletion. It all points to either git, the NFS server, or a prankster.
Strange!
^ permalink raw reply
* Re: [PATCHv3] Add branch management for releases to gitworkflows
From: skillzero @ 2009-11-12 20:08 UTC (permalink / raw)
To: rocketraman; +Cc: git, trast, gitster
In-Reply-To: <1258055164-11876-2-git-send-email-rocketraman@fastmail.fm>
> +.Update maint to new release
> +[caption="Recipe: "]
> +=====================================
> +* `git branch -f next master`
> +* `git merge ai/topic_in_next1`
> +* `git merge ai/topic_in_next2`
Shouldn't that be something like "Update next to new release" instead
of "maint"?
Should it also have 'git checkout next' after the branch command so
it's on next before merging?
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Felipe Contreras @ 2009-11-12 20:04 UTC (permalink / raw)
To: Michael J Gruber
Cc: Jonathan Nieder, Junio C Hamano, git, J. Bruce Fields,
Hannu Koivisto, Jeff King, Wincent Colaiuta, Matthias Lederhofer
In-Reply-To: <4AFBF18E.7070906@drmicha.warpmail.net>
On Thu, Nov 12, 2009 at 1:29 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Feel free to bring this issue on for a change in Git 1.7.0. It would be
> good to research any possible incompatibilities this would imply (other
> than the looks of the output),
Isn't that what we are doing just now?
> The process can be frustrating at times. Many patches go through many
> rounds. I've had occasions where I got frustrated and gave up, as well
> as those where I learned a lot and the actual result was much better
> than it would have been without thorough discussions. It's this process
> which tries to ensure that the project is moving forward most of the
> time, rather than sporadically back and forth; moving forward maybe a
> bit slower, but still at an impressive overall rate.
Except in this case there is no path forward. If there is, I would
like to hear it.
> Regarding this specific patch series: I took part in the initial
> discussion, and got frustrated by the original poster's seemingly
> unwillingness to accept advice, so I left. I'm not drawing any general
> conclusions, and please don't take this as an ad hominem argument.
> Sometimes it's simply a matter of mismatching participants.
What are you talking about? All your comments were addressed in
subsequent patches, as the commit message of the patch in this thread
points out.
Moreover, in the paragraph before you argued that these thorough
discussions are actually a good thing. Or are patch committers not
allowed to discuss?
> I didn't read that out of the survey. On the other hand, the last survey
> pretty impressively showed where it had been publicized most
> prominently. One should keep that in mind when interpreting the results.
So? What are the surveys supposed to be for, if not to use the results?
> If you care to go back to that discussion you see that there is good
> reason for having both --cached and --index. They are different. "git
> help cli" explains this nicely.
"good" is a very subjective term; I don't think "they are different"
is a good reason. By that logic --only-index and
--index-and-working-dir serve the same purpose, just like --gogo and
--dance.
But there's no point in discussing this until people accept there is a
problem, and there seems to be unwillingness to accept that very few
people use the stage properly.
> "To stage" has been introduced to describe what "git add" does to people
> who hard wire "add" to the meaning it has in other VCSes. In fact, this
> would be unnecessary if the concept of Git as a *content* tracker could
> be transmitted more successfully. Git cares about content only, so what
> could "git add" possibly mean?
usage: git add [options] [--] <filepattern>...
I don't see any mention of this "blob" mythical creature. In the vast
majority of the minds of git users, 'git add' adds files to the
repository, just like any other VCS.
Proof of that is that only 23% of the people use "git add -i / -p" and
15% "git add -u / -A" often.
> "git stage" is a failed follow up ui experiment.
I agree with that. But assuming because one UI experiment failed, all
other "stage" proposals are doomed.
> In this regard, I think the problem is that there are really two kinds
> of people in terms of learning style:
>
> - Some prefer recipes, similarities with previously known recipes. "How
> do I...?" And then try do understand "How does (G)it...?" from that.
>
> - Some want to understand concepts first: "How does (G)it...?" And then
> figure out how to use (G)it to do what they want.
>
> I'd guess most developers and a large fraction of the "technical crowd"
> belong in the second camp.
I actually belong to the two groups. When I started to use git I
learned it through recipes and grew fond of it, but didn't really know
what was really happening even thought I used it for years. It wasn't
until a colleague recommended me to read "Git from the bottom up",
then I really started to understand git and realized I didn't know
squat. Sure, I heard concepts such as "feature branches", "rebase" and
"stage interactive", and I had in my to-do list to learn them, but
that was it.
I'm pretty sure the vast majority of users are in the darkness just as I was.
> I still think we should both
What?
> - try and teach concepts early, emphasize that Git is different
> (content, index, branch - that's it)
Well, that's the first failure right there. If your objective is to
confuse people, then sure, call it "index", otherwise choose a name
that corresponds with it's purpose: stage.
> - make Git behave in "expected ways", making it easy for the (willing)
> beginner) without compromising its usefulness as a power tool.
Sure, but if the UI was more friendly people would learn to use the
advanced features through it's use. Currently there are no ropes to do
that. You have to read a book or something.
--
Felipe Contreras
^ permalink raw reply
* Re: git svn show-ignore bug?
From: Niko Schwarz @ 2009-11-12 19:55 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20091112184155.GA4390@dcvr.yhbt.net>
Hi,
so I spoke to the SVN admin and he says that possibly the repo has
been corrupted a while ago. The command you asked me to run fails, it
can't authenticate. That command was svn pg -R svn:ignore
https://www.iam.unibe.ch/scg/svn_repos.
Some old version in the repo may be corrupt and I didn't get the details.
So, well, I guess it's nothing you can do :)
Niko
On Thu, Nov 12, 2009 at 7:41 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Niko Schwarz <niko.schwarz@googlemail.com> wrote:
>> Hi there, in the IRC channel today, someone asked me to report this
>> behavior to you because they suspect a bug in show-ignore.
>>
>> Ok, so here's the output of git svn info:
>>
>> Path: .
>> URL: https://www.iam.unibe.ch/scg/svn_repos
>> Repository Root: https://www.iam.unibe.ch/scg/svn_repos
>> Repository UUID: 54883e8d-cf1d-0410-83d6-f114b9419f37
>> Revision: 29639
>> Node Kind: directory
>> Schedule: normal
>> Last Changed Author: oscar
>> Last Changed Rev: 29639
>> Last Changed Date: 2009-11-12 11:22:35 +0100 (Do, 12 Nov 2009)
>>
>>
>> I can do git svn rebase, git svn fetch, and those things work. Dcommit,
>> works, too. But git svn show-ignore >> .gitignore does not work.
>
> Hi Niko, this is really strange, especially when dcommit works.
>
>> This is the dialog with the system:
>> Nikos-Mbp-3:svn_repos niko$ git svn show-ignore >> .gitignore
>> Authentication realm: <https://www.iam.unibe.ch:443> SCG Subversion
>> Repository
>> Password for 'schwarz':
>> Authentication realm: <https://www.iam.unibe.ch:443> SCG Subversion
>> Repository
>> Username: schwarz
>> Password for 'schwarz':
>> Authentication realm: <https://www.iam.unibe.ch:443> SCG Subversion
>> Repository
>> Username: schwarz
>> Password for 'schwarz':
>> Autorisierung schlug fehl: PROPFIND von »/scg/svn_repos/IAM«:
>> Autorisierung schlug fehl: Could not authenticate to server: rejected
>> Basic challenge (https://www.iam.unibe.ch) at /opt/local/libexec/git-
>> core/git-svn line 2276
>>
>>
>> That's all the info I have, I'm afraid. I'm sure that the password is
>> correct, as it works from XCode.
>
> Which version of git is this? Are you in contact with the SVN server
> administrator? Maybe they can look at server logs for you.
>
> Also, can you try the following command with plain svn?
>
> svn pg -R svn:ignore https://www.iam.unibe.ch/scg/svn_repos
>
> Thanks. Also, if anybody else there can help look into this it would be
> greatly appreciated, my authentication knowledge is still a bit on the
> weak side.
>
> --
> Eric Wong
>
^ permalink raw reply
* [PATCHv3] Add branch management for releases to gitworkflows
From: rocketraman @ 2009-11-12 19:46 UTC (permalink / raw)
To: git; +Cc: trast, gitster
In-Reply-To: <1258055164-11876-1-git-send-email-rocketraman@fastmail.fm>
From: Raman Gupta <raman@rocketraman.com>
The current man page does a reasonable job at describing branch management
during the development process, but it does not contain any guidance as to
how the branches are affected by releases.
Add a basic introduction to the branch management undertaken during a
git.git release, so that a reader may gain some insight into how the
integration, maintenance, and topic branches are affected during the
release transition, and is thus able to better design the process for their
own project.
Other release activities such as reviews, testing, and creating
distributions are currently out of scope.
---
Documentation/gitworkflows.txt | 108 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 108 insertions(+), 0 deletions(-)
diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
index 2b021e3..7000930 100644
--- a/Documentation/gitworkflows.txt
+++ b/Documentation/gitworkflows.txt
@@ -209,6 +209,114 @@ chance to see if their in-progress work will be compatible. `git.git`
has such an official throw-away integration branch called 'pu'.
+Branch management for a release
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Assuming you are using the merge approach discussed above, when you
+are releasing your project you will need to do some additional branch
+management work.
+
+Creating a release is easy. Since 'master' is tracking the commits
+that should go into the next feature release, simply tag the tip of
+'master' with a tag indicating the release version.
+
+.Release tagging
+[caption="Recipe: "]
+=====================================
+`git tag -s -m "GIT X.Y.Z" vX.Y.Z master`
+=====================================
+
+Similarly, for a maintenance release, 'maint' is tracking the commits
+to be released. Therefore, simply replace 'master' above with
+'maint'.
+
+Generally, you should push the new tag to a public git server (see
+"DISTRIBUTED WORKFLOWS" below). This push makes the tag available to
+others tracking your project. The push could also trigger a
+post-update hook to perform release-related items such as building
+documentation.
+
+
+Maintenance branch management after a feature release
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+After a feature release, you need to manage your maintenance branches.
+
+First, if you wish to continue to release maintenance fixes for the
+feature release made before the recent one, then you must create
+another branch to track commits for that previous release.
+
+To do this, the current maintenance branch is copied to another branch
+named with the previous release version number (e.g. maint-X.Y.(Z-1)
+where X.Y.Z is the current release).
+
+.Copy maint
+[caption="Recipe: "]
+=====================================
+`git branch maint-X.Y.(Z-1) maint`
+=====================================
+
+The 'maint' branch should now be fast forwarded to the newly released
+code so that maintenance fixes can be tracked for the current release:
+
+.Update maint to new release
+[caption="Recipe: "]
+=====================================
+* `git checkout maint`
+* `git merge master`
+=====================================
+
+This 'should' fast forward 'maint' from 'master'. If it is not a fast
+forward, then 'maint' contained some commits that were not included on
+'master', which means that the recent feature release could be missing
+some fixes made on 'maint'. The exception is if there were any commits
+that were cherry-picked to 'maint' as described above in "Merging
+upwards". In this case, the merge will not be a fast forward.
+
+An alternative approach to updating the 'maint' branch, though one
+not used in git.git, is to rename the current 'maint' branch to track
+maintenance fixes for the older release and then to recreate 'maint'
+from 'master':
+
+ $ git branch -m maint maint-X.Y.(Z-1)
+ $ git branch maint master
+
+The latter step will create a new 'maint' branch based on 'master'. If
+commits were cherry-picked to 'maint', then this will create a new
+'maint' branch without a merge commit.
+
+
+Branch management for next and pu after a feature release
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+After a feature release, the 'next' testing branch may optionally be
+rewound and rebuilt from the tip of 'master' using the surviving
+topics on 'next':
+
+.Update maint to new release
+[caption="Recipe: "]
+=====================================
+* `git branch -f next master`
+* `git merge ai/topic_in_next1`
+* `git merge ai/topic_in_next2`
+* ...
+=====================================
+
+The advantage of doing this is that the history of 'next' will be
+clean. For example, some topics merged into 'next' may have initially
+looked promising, but were later found to be undesirable or premature.
+In such a case, the topic is reverted out of 'next' but the fact
+remains in the history that it was once merged and reverted. By
+recreating 'next', you give another incarnation of such topics a clean
+slate to retry, and a feature release is a good point in history to do
+so.
+
+If you do this, then you should make a public announcement indicating
+that 'next' was rewound and rebuilt.
+
+The same process may be followed for 'pu'.
+
+
DISTRIBUTED WORKFLOWS
---------------------
--
1.6.2
^ permalink raw reply related
* Add branch management for releases to gitworkflows
From: rocketraman @ 2009-11-12 19:46 UTC (permalink / raw)
To: git; +Cc: trast, gitster
Version 3 of the gitworkflows patch follows.
This version of the patch attempts to incorporate all feedback received from Junio and Thomas. The main changes are:
1) Consistent use of pronouns in the imperative.
2) Reorganization to move the new text into the "MANAGING BRANCHES" section. This wasn't explicitly suggested by Junio or Thomas, but it makes sense as it clarifies that the content is not about releases in general, but how releases affect the branch structure previously described in the document.
3) Largely modified and reworded text, to conform to the new reorganization and to include feedback from Junio and Thomas.
Cheers,
Raman
^ permalink raw reply
* Re: git svn show-ignore bug?
From: Eric Wong @ 2009-11-12 18:41 UTC (permalink / raw)
To: Niko Schwarz; +Cc: git
In-Reply-To: <01C132B1-3CEE-4EF2-A4BC-5C1D71088FBF@gmail.com>
Niko Schwarz <niko.schwarz@googlemail.com> wrote:
> Hi there, in the IRC channel today, someone asked me to report this
> behavior to you because they suspect a bug in show-ignore.
>
> Ok, so here's the output of git svn info:
>
> Path: .
> URL: https://www.iam.unibe.ch/scg/svn_repos
> Repository Root: https://www.iam.unibe.ch/scg/svn_repos
> Repository UUID: 54883e8d-cf1d-0410-83d6-f114b9419f37
> Revision: 29639
> Node Kind: directory
> Schedule: normal
> Last Changed Author: oscar
> Last Changed Rev: 29639
> Last Changed Date: 2009-11-12 11:22:35 +0100 (Do, 12 Nov 2009)
>
>
> I can do git svn rebase, git svn fetch, and those things work. Dcommit,
> works, too. But git svn show-ignore >> .gitignore does not work.
Hi Niko, this is really strange, especially when dcommit works.
> This is the dialog with the system:
> Nikos-Mbp-3:svn_repos niko$ git svn show-ignore >> .gitignore
> Authentication realm: <https://www.iam.unibe.ch:443> SCG Subversion
> Repository
> Password for 'schwarz':
> Authentication realm: <https://www.iam.unibe.ch:443> SCG Subversion
> Repository
> Username: schwarz
> Password for 'schwarz':
> Authentication realm: <https://www.iam.unibe.ch:443> SCG Subversion
> Repository
> Username: schwarz
> Password for 'schwarz':
> Autorisierung schlug fehl: PROPFIND von »/scg/svn_repos/IAM«:
> Autorisierung schlug fehl: Could not authenticate to server: rejected
> Basic challenge (https://www.iam.unibe.ch) at /opt/local/libexec/git-
> core/git-svn line 2276
>
>
> That's all the info I have, I'm afraid. I'm sure that the password is
> correct, as it works from XCode.
Which version of git is this? Are you in contact with the SVN server
administrator? Maybe they can look at server logs for you.
Also, can you try the following command with plain svn?
svn pg -R svn:ignore https://www.iam.unibe.ch/scg/svn_repos
Thanks. Also, if anybody else there can help look into this it would be
greatly appreciated, my authentication knowledge is still a bit on the
weak side.
--
Eric Wong
^ permalink raw reply
* Re: BUG: git rebase -i -p silently looses commits
From: Greg Price @ 2009-11-12 17:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Constantine Plotnikov, git
In-Reply-To: <alpine.DEB.1.00.0911111804520.19111@intel-tinevez-2-302>
On Wed, Nov 11, 2009 at 12:32 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> That is very interesting!
>
> However, for rebase-i-p to have a chance to be accepted, I think a few
> things are necessary still (this is all from memory, so please take
> everything with a grain of salt):
Great, this is helpful, and it overlaps with my existing to-do list.
I have a couple of questions.
> - reorder the series to have the -i fixes first, the new commands next,
> and then the changes to the actual -p mode
This one will be easy when everything else is ready, I think.
> - rework the mark stuff so that 'todo' works properly, and then change the
> system to use ':<name>' style bookmarks.
This is the biggest change I was going to suggest! Glad we're on the
same page. To be clear, what I want to do here is
- add a 'mark' command
- emit 'mark' commands in the TODO generation for the target of each
'goto', and use them.
Is that also what you had in mind?
> - fix that nasty bug which makes one revision not pass the tests (I forgot
> which one, but it should be in the TODOs)
Hmm. I see one TODO comment in your patches, and it doesn't sound
like this. Is there a TODO somewhere else that I'm missing?
Alternatively, I can always end up just running the tests on all the
revisions and find out.
> - add proper handling for the case when a patch has been applied in
> upstream already, but was not correctly identified as that by
> --cherry-pick (well, this TODO is actually not really related to rebase
> -i -p, but something I deeply care about)
Hmm. I'll have to think about what the behavior could be here.
Unless you've already worked out a behavior you would like to see?
For context, I think the issue you're referring to is that sometimes
the patch-id changed, so that --cherry-pick doesn't identify the
patch; and then some later upstream patch has touched the same code
again, so that there's a conflict when we try to apply the older
patch. I would also like to see this fixed, but I don't see offhand
what the right behavior would be.
The "read my mind" behavior might be something like, somewhere between
the merge-base and the upstream there is a commit after which this one
would apply as no changes, so let's say that commit already applied
this patch. But that could be the wrong thing if e.g. a patch was
applied and later reverted. And I don't know offhand how to implement
it efficiently.
Anyway, I think you're right that this improvement is orthogonal to
rebase -i -p.
> Unfortunately, I am getting more and more deprived of Git time budget
> these days, so that I cannot seem to find a few hours to at least restart
> my efforts.
Understood. I may have some time to work on this soon, we'll see. I
think the priorities will be to
- add "mark" as you say
- add the "pause" command, to make it possible to amend a merge
- write tests
- fix a couple of bugs, track down the one you mentioned
- write documentation
At that point, and with the reordering you suggested, I think it will
be ready to submit for inclusion.
Further comments, and bug reports from anyone else using the
development version, are welcome.
Thanks,
Greg
^ permalink raw reply
* [PATCH] (to improve gitosis support) CVS Server: Support reading base and roots from environment
From: Phil Miller @ 2009-11-12 17:25 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]
The Gitosis single-account Git/ssh hosting system runs git commands
through git-shell after confirming that the connecting user is
authorized to access the requested repository. This works well for
upload-pack and receive-pack, which take a repository argument through
git-shell. This doesn't work so well for `cvs server', which is passed
through literally, with no arguments. Allowing arguments risks
sneaking in `--export-all', so that restriction should be maintained.
Despite that, passing a list of repository roots is necessary for
per-user access control by the hosting software, and passing a base
path improves usability without weakening security. Thus,
git-cvsserver needs to come up with these values at runtime by some
other means. Since git-shell preserves the environment for other
purposes, the environment can carry these arguments as well.
Thus, modify git-cvsserver to read $GIT_CVSSERVER_{BASE_PATH,ROOTS} in
the absence of equivalent command line arguments.
Signed-off-by: Phil Miller <mille121@illinois.edu>
[-- Attachment #2: 0001-CVS-Server-Support-reading-base-and-roots-from-envir.patch --]
[-- Type: text/x-diff, Size: 3480 bytes --]
From f5c911ab8d7f17d2676fc520539f0e87f4cfe015 Mon Sep 17 00:00:00 2001
From: Phil Miller <mille121@illinois.edu>
Date: Wed, 14 Oct 2009 23:20:09 -0500
Subject: [PATCH] CVS Server: Support reading base and roots from environment
The Gitosis single-account Git/ssh hosting system runs git commands
through git-shell after confirming that the connecting user is
authorized to access the requested repository. This works well for
upload-pack and receive-pack, which take a repository argument through
git-shell. This doesn't work so well for `cvs server', which is passed
through literally, with no arguments. Allowing arguments risks
sneaking in `--export-all', so that restriction should be maintained.
Despite that, passing a list of repository roots is necessary for
per-user access control by the hosting software, and passing a base
path improves usability without weakening security. Thus,
git-cvsserver needs to come up with these values at runtime by some
other means. Since git-shell preserves the environment for other
purposes, the environment can carry these arguments as well.
Thus, modify git-cvsserver to read $GIT_CVSSERVER_{BASE_PATH,ROOTS} in
the absence of equivalent command line arguments.
Signed-off-by: Phil Miller <mille121@illinois.edu>
---
git-cvsserver.perl | 21 ++++++++++++++++++++-
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 6dc45f5..9e58d2a 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -104,6 +104,7 @@ $log->info("--------------- STARTING -----------------");
my $usage =
"Usage: git cvsserver [options] [pserver|server] [<directory> ...]\n".
" --base-path <path> : Prepend to requested CVSROOT\n".
+ " Can be read from GIT_CVSSERVER_BASE_PATH\n".
" --strict-paths : Don't allow recursing into subdirectories\n".
" --export-all : Don't check for gitcvs.enabled in config\n".
" --version, -V : Print version information and exit\n".
@@ -111,7 +112,8 @@ my $usage =
"\n".
"<directory> ... is a list of allowed directories. If no directories\n".
"are given, all are allowed. This is an additional restriction, gitcvs\n".
- "access still needs to be enabled by the gitcvs.enabled config option.\n";
+ "access still needs to be enabled by the gitcvs.enabled config option.\n".
+ "Alternately, these directories may be specified in GIT_CVSSERVER_ROOTS.\n";
my @opts = ( 'help|h|H', 'version|V',
'base-path=s', 'strict-paths', 'export-all' );
@@ -148,6 +150,23 @@ if ($state->{'export-all'} && !@{$state->{allowed_roots}}) {
die "--export-all can only be used together with an explicit whitelist\n";
}
+# Environment handling for running under git-shell
+if ($ENV{GIT_CVSSERVER_BASE_PATH}) {
+ if ($state->{'base-path'}) {
+ die "Cannot specify base path both ways.\n";
+ }
+ my $base_path = $ENV{GIT_CVSSERVER_BASE_PATH};
+ $state->{'base-path'} = $base_path;
+ $log->debug("Picked up base path '$base_path' from environment.\n");
+}
+if ($ENV{GIT_CVSSERVER_ROOTS}) {
+ if (@{$state->{allowed_roots}}) {
+ die "Cannot specify roots both ways: @ARGV\n";
+ }
+ my @allowed_root = split(',', $ENV{GIT_CVSSERVER_ROOTS});
+ $state->{allowed_roots} = [ @allowed_root ];
+}
+
# if we are called with a pserver argument,
# deal with the authentication cat before entering the
# main loop
--
1.6.5.2.411.gf7c0f.dirty
^ permalink raw reply related
* Re: Idea for git-touch
From: Michele Ballabio @ 2009-11-12 17:18 UTC (permalink / raw)
To: Luís Sousa; +Cc: git
In-Reply-To: <4AFC348B.4000202@ualg.pt>
On Thursday 12 November 2009, Luís Sousa wrote:
> I normally do commits when something works or on the end of the day,
> just to record what have doing. On other day, when I consider that is
> done/working I do a rebase -i squashing everything on one commit. The
> date of that commit will be preserved and is the date of the first
> commit. Then I do a git-reset HEAD~1, git-add . and git-commit with the
> same message to have the current date.
git rebase -i <...>
git rebase --ignore-date <...>
should do what you need.
^ permalink raw reply
* Re: Idea for git-touch
From: Luís Sousa @ 2009-11-12 17:13 UTC (permalink / raw)
To: Jan Krüger; +Cc: git
In-Reply-To: <20091112180841.001ae651@perceptron>
Yeah, but still need some copy&paste of message :)
Jan Krüger wrote:
> On Thu, 12 Nov 2009 17:05:21 +0000, Luís Sousa <llsousa@ualg.pt> wrote:
>
>> But still preserves the original date, isn't it?
>>
>
> Yes, and I just remembered that, too. Sorry. Today is not my day.
>
> Even so, you can still save one command:
>
> git reset --soft HEAD^
> git commit
>
> Jan
>
>
>
^ permalink raw reply
* Re: Idea for git-touch
From: Jan Krüger @ 2009-11-12 17:08 UTC (permalink / raw)
To: Luís Sousa; +Cc: git
In-Reply-To: <4AFC4051.5030607@ualg.pt>
On Thu, 12 Nov 2009 17:05:21 +0000, Luís Sousa <llsousa@ualg.pt> wrote:
> But still preserves the original date, isn't it?
Yes, and I just remembered that, too. Sorry. Today is not my day.
Even so, you can still save one command:
git reset --soft HEAD^
git commit
Jan
^ permalink raw reply
* Re: Idea for git-touch
From: Luís Sousa @ 2009-11-12 17:05 UTC (permalink / raw)
To: git
In-Reply-To: <20091112180132.5819f963@perceptron>
But still preserves the original date, isn't it?
Jan Krüger wrote:
> Hi Luís,
>
>
>> [...] Then I do a git-reset HEAD~1, git-add . and git-commit with
>> the same message to have the current date.
>>
>
> There is an existing command that does pretty much exactly that:
> git commit --amend.
>
> Jan
>
>
>
^ permalink raw reply
* Re: [PATCHv2] Update gitworkflows man page to include release workflow
From: Raman Gupta @ 2009-11-12 16:54 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, git
In-Reply-To: <200911120910.57091.trast@student.ethz.ch>
Thomas Rast wrote:
> Raman Gupta wrote:
>> Junio C Hamano wrote:
>>> Please set the tone straight. If this is to suggest various possible
>>> workflows in general vague terms, "may use" would be good. If this is to
>>> precisely describe what I do, then there won't be "you could do this, or
>>> you could do that." Your "may use" suggests the former, but the commit
>>> log message claims the latter. Which document are you writing?
>> Ok. The current document is inconsistent. In places it uses "the
>> maintainer" and in other places it uses "you". In any case, it seems
>> that the "maintainer" here is not "Junio Hamano" -- rather, it is the
>> reader.
>>
>> Let me create a separate (and first) cleanup patch to fix the existing
>> inconsistencies in this man page. I would prefer to use the pronoun
>> "you" consistently as also suggested by Thomas Rast.
>
> Well, I'm not sure if this is also in reply to my comment
It was mostly, yes.
> } The current gitworkflows is mostly formulated in the imperative, [...]
> } or by directly describing the tools in the third person, [...]
>
> but note that I do not consider the current form to be inconsistent
> (though you may of course convince me otherwise). It addresses the
> presumed user with "you", which is not always the maintainer. For
> example, when talking about patch submission we have
You're right, upon re-reading the original man page I realized it is
consistent.
Thanks,
Raman
^ permalink raw reply
* Re: Idea for git-touch
From: Jan Krüger @ 2009-11-12 17:01 UTC (permalink / raw)
To: Luís Sousa; +Cc: git
In-Reply-To: <4AFC348B.4000202@ualg.pt>
Hi Luís,
> [...] Then I do a git-reset HEAD~1, git-add . and git-commit with
> the same message to have the current date.
There is an existing command that does pretty much exactly that:
git commit --amend.
Jan
^ permalink raw reply
* Re: Working on merged branches whilst seeing current master
From: rhlee @ 2009-11-12 16:49 UTC (permalink / raw)
To: git
In-Reply-To: <1258030118389-3992599.post@n2.nabble.com>
Tim Mazid wrote:
>
> Actually, there's no reason you couldn't just 'git reset HEAD^' once you
> realise that the branch isn't ready. If you want to see the changes from
> master, you could just merge that into your branch. If you just want to
> see the content in master, you could use gitk or gitg, which allows you to
> view files at any commit.
>
> Personally, I merge master into my branches, test and check, and fix, then
> merge the branch into master. This sometimes results in a fast-forward, if
> you haven't made changes to master. If you don't like that, you can always
> use the --no-ff option, though.
>
I don't think 'git reset HEAD^' would work in my case as that only goes back
one commit. I may have made many other changes on the master branch that I
want to keep.
By merging from master into your branch, like you said, you get a nice graph
view that shows what you've brought into your branch from master since you
last left off. But doesn't this goes against the idea that branches should
be independent, by bringing in changes from master?
--
View this message in context: http://n2.nabble.com/Working-on-merged-branches-whilst-seeing-current-master-tp3987667p3994102.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Idea for git-touch
From: Luís Sousa @ 2009-11-12 16:15 UTC (permalink / raw)
To: git
Hi all,
I have been using GIT for several time and I love it.
I normally do commits when something works or on the end of the day,
just to record what have doing. On other day, when I consider that is
done/working I do a rebase -i squashing everything on one commit. The
date of that commit will be preserved and is the date of the first
commit. Then I do a git-reset HEAD~1, git-add . and git-commit with the
same message to have the current date.
A nice functionality was a git-touch that did the commands before.
Best regards and keep the good work,
Luís Sousa
P.S.: While writing this message I realize that is easy to accomplish a
git-touch doing a bash script, but probably is a good idea to share.
^ permalink raw reply
* Re: get git not to care about permissions
From: Thomas Rast @ 2009-11-12 16:10 UTC (permalink / raw)
To: Matt Schoen; +Cc: Jay Soffian, git
In-Reply-To: <3cf217d80911120744g5e020003rc00c460fff0bff1d@mail.gmail.com>
Matt Schoen wrote:
> error: Unable to open
> /ad/eng/courses/ec/ec464/ec464-team03/test.git/HEAD.lock for writing
>
> ls -al in the directory gives me:
> total 12
> drwx------ 3 schoen root 4096 Nov 12 10:41 .
> d--------- 7 root root 4096 Nov 12 10:41 ..
> -rwx------ 1 schoen root 0 Nov 12 10:41 HEAD.lock
At least in my current copy, this can only come from
// lock.c:1371
lockpath = mkpath("%s.lock", git_HEAD);
fd = open(lockpath, O_CREAT | O_EXCL | O_WRONLY, 0666);
if (fd < 0) {
error("Unable to open %s for writing", lockpath);
It prints an absolute path, so the open() also accesses an absolute
path (though I don't know why it insists on that).
But the above directory listing would indicate that you do not even
have permission to look inside your $(pwd) by absolute path...
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH v2] git-pull.sh --rebase: overhaul error handling when no candidates are found
From: Jan Krüger @ 2009-11-12 16:08 UTC (permalink / raw)
To: Jeff King; +Cc: Jan Nieuwenhuizen, Tomas Carnecky, git list, Junio C Hamano
In-Reply-To: <20091112150626.GA24848@coredump.intra.peff.net>
* The longish error message displayed when the user uses "git pull" but
has no remote/merge/rebase lines configured for the current branch
contains example configuration to remedy the situation... but the
example uses a rather invalid syntax, using the dotted syntax "git
config" accepts, but also "=" separators which are used in the config
file format. It also implies that this syntax is valid in git config
files. This changes the example to use valid config file syntax.
* When git pull --rebase is used, error_on_no_merge_candidates still
thinks we're trying to merge, so the resulting message talks about
merge all the time. This makes the message depend on the mode of
operation.
Signed-off-by: Jan Krüger <jk@jk.gs>
---
So this still uses config file syntax, but the erroneous check for
using the "rebase" setting is gone. Instead, if --rebase is in effect,
include "rebase = true" in the sample config snippet.
By the way, Jeff, it's precisely your patch that confused me into
thinking there was a bug. I sort of assumed the messages you added had
already been there in the version Jan N. is using. Stupid assumption, I
guess.
git-pull.sh | 41 ++++++++++++++++++++++++++---------------
1 files changed, 26 insertions(+), 15 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 37f3d93..315ec51 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -91,45 +91,56 @@ error_on_no_merge_candidates () {
esac
done
+ if [ true = "$rebase" ]; then
+ op_type=rebase
+ op_prep=against
+ else
+ op_type=merge
+ op_prep=with
+ fi
+
curr_branch=${curr_branch#refs/heads/}
upstream=$(git config "branch.$curr_branch.merge")
remote=$(git config "branch.$curr_branch.remote")
if [ $# -gt 1 ]; then
- echo "There are no candidates for merging in the refs that you just fetched."
+ echo "There are no candidates for using the refs that you just fetched."
echo "Generally this means that you provided a wildcard refspec which had no"
echo "matches on the remote end."
elif [ $# -gt 0 ] && [ "$1" != "$remote" ]; then
echo "You asked to pull from the remote '$1', but did not specify"
- echo "a branch to merge. Because this is not the default configured remote"
+ echo "a branch to use. Because this is not the default configured remote"
echo "for your current branch, you must specify a branch on the command line."
elif [ -z "$curr_branch" ]; then
echo "You are not currently on a branch, so I cannot use any"
echo "'branch.<branchname>.merge' in your configuration file."
- echo "Please specify which branch you want to merge on the command"
+ echo "Please specify which branch you want to use on the command"
echo "line and try again (e.g. 'git pull <repository> <refspec>')."
echo "See git-pull(1) for details."
elif [ -z "$upstream" ]; then
echo "You asked me to pull without telling me which branch you"
- echo "want to merge with, and 'branch.${curr_branch}.merge' in"
- echo "your configuration file does not tell me either. Please"
- echo "specify which branch you want to merge on the command line and"
+ echo "want to $op_type $op_prep, and 'branch.${curr_branch}.merge' in"
+ echo "your configuration file does not tell me either. Please"
+ echo "specify which branch you want to use on the command line and"
echo "try again (e.g. 'git pull <repository> <refspec>')."
echo "See git-pull(1) for details."
echo
- echo "If you often merge with the same branch, you may want to"
- echo "configure the following variables in your configuration"
- echo "file:"
+ echo "If you often $op_type $op_prep the same branch, you may want to"
+ echo "use something like the following in your configuration file:"
echo
- echo " branch.${curr_branch}.remote = <nickname>"
- echo " branch.${curr_branch}.merge = <remote-ref>"
- echo " remote.<nickname>.url = <url>"
- echo " remote.<nickname>.fetch = <refspec>"
+ echo " [branch \"${curr_branch}\"]"
+ echo " remote = <nickname>"
+ echo " merge = <remote-ref>"
+ test rebase = "$op_type" &&
+ echo " rebase = true"
+ echo " [remote \"<nickname>\"]"
+ echo " url = <url>"
+ echo " fetch = <refspec>"
echo
echo "See git-config(1) for details."
else
- echo "Your configuration specifies to merge the ref '${upstream#refs/heads/}' from the"
- echo "remote, but no such ref was fetched."
+ echo "Your configuration specifies to $op_type $op_prep the ref '${upstream#refs/heads/}'"
+ echo "from the remote, but no such ref was fetched."
fi
exit 1
}
--
1.6.5.2.156.g89436
^ permalink raw reply related
* Re: get git not to care about permissions
From: Matt Schoen @ 2009-11-12 15:44 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <76718490911112144n6837d02cw94d608bcbc74855a@mail.gmail.com>
The only output I get is:
warning: templates not found /tmp/git/share/git-core/templates
error: Unable to open
/ad/eng/courses/ec/ec464/ec464-team03/test.git/HEAD.lock for writing
ls -al in the directory gives me:
total 12
drwx------ 3 schoen root 4096 Nov 12 10:41 .
d--------- 7 root root 4096 Nov 12 10:41 ..
-rwx------ 1 schoen root 0 Nov 12 10:41 HEAD.lock
drwx------ 4 schoen root 4096 Nov 12 10:41 refs
As I understand it, because we use Kerberos, permissions on everything
must be set to 700 at most. I think the issue here comes from the
fact that git wants to use group permissions. This is my guess.
On Thu, Nov 12, 2009 at 12:44 AM, Jay Soffian <jaysoffian@gmail.com> wrote:
> On Wed, Nov 11, 2009 at 4:17 PM, sconeman <schoen@bu.edu> wrote:
>> does. Git doesn't like this and won't even create a bare repository. Is
>> there any way I can get git to ignore permissions and just do what it needs
>> to do?
>
> And the output from "git init --bare" is?
>
> j.
>
>
^ permalink raw reply
* Re: get git not to care about permissions
From: Matt Schoen @ 2009-11-12 15:47 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580911120728j2f9995basb554b0a493a364bf@mail.gmail.com>
Thanks for the tip, Eugene, but I'm not sure if this helps me.
I'm trying to set up the repo on a shared directory, which isn't
actually on a physical computer (NetApp is basically a
data-server-in-a-box, and as such I do not directly interface with
it). Thus, I must access the directory over the school network, which
uses Kerberos security. I think it is this restriction that is giving
git its issues.
On Thu, Nov 12, 2009 at 10:28 AM, Eugene Sajine <euguess@gmail.com> wrote:
>>>
>>> On Nov 9, 2009 11:06 AM, "sconeman" <schoen@bu.edu> wrote:
>>>
>>>
>>> Hello,
>>>
>>> I'm trying to set up git on a NetApp drive at my school, BU. The NetApp
>>> shares are configured with Windows permissions, and I forget the specifics
>>> (which I can figure out if needed) about why this is the case, but basically
>>> the deal is that if true UNIX permissions were to be used, Windows wouldn't
>>> be able to read the drive. As such, and because we use the Kerberos
>>> ticketing system, the permissions for the drive are set up such that the
>>> owners (myself and my team members) have full permissions, but nobody else
>>> does. Git doesn't like this and won't even create a bare repository. Is
>>> there any way I can get git to ignore permissions and just do what it needs
>>> to do?
>>>
>>> Thanks in advance for the help!
>>>
>>> -Matt
>> --
> On Wed, Nov 11, 2009 at 4:34 PM, Eugene Sajine <euguess@gmail.com> wrote:
>> Hi,
>>
>> I had almost similar issue - bare repos in my case should be set up under
>> user which only few guys are having password from. So what I did is just a
>> small program which creates the bare repo locally and makes secure copy to
>> this user home. All authentication is hidden from the end user. Then users
>> can access their repos via git protocol. Ialso fillthe repo with some
>> additional info for cgit.
>>
>> Eugene
>
> BTW I'm using "git clone --bare" in this process, so if you have a
> repo with working copy you can create a bare one separately, put it on
> the server and then connect to it via "git remote add"
>
> Eugene
>
>
^ permalink raw reply
* Re: [PATCH] git-pull.sh: overhaul error handling when no candidates are found
From: Jeff King @ 2009-11-12 15:28 UTC (permalink / raw)
To: Jan Krüger
Cc: Jan Nieuwenhuizen, Tomas Carnecky, git list, Junio C Hamano
In-Reply-To: <20091112162558.6b1c4a43@perceptron>
On Thu, Nov 12, 2009 at 04:25:58PM +0100, Jan Krüger wrote:
> > Personally, I would go the other way: give them something they can cut
> > and paste on the command line, like:
>
> A matter of taste, I suppose. The user has to edit the lines anyway
> since they contain placeholders.
Oh, true. I was thinking we filled them in with the right values, but of
course we don't know what those values are (if we did, we wouldn't be
bugging the user...). So ignore what I said.
> > Isn't branch.*.rebase a boolean value?
>
> Argh! Of course it is. Note to self: don't write patches in a hurry.
> Disregard everything I said. I thought I was seeing incorrect behavior
> in what Jan (N.) reported...
If it makes you feel better, the reason I noticed your error so quickly
is that I made the _exact_ same one while doing a patch in that area a
month or two ago.
-Peff
^ permalink raw reply
* Re: get git not to care about permissions
From: Eugene Sajine @ 2009-11-12 15:28 UTC (permalink / raw)
To: sconeman; +Cc: git
In-Reply-To: <76c5b8580911111334p76232995qbd6bf6b06d250854@mail.gmail.com>
>>
>> On Nov 9, 2009 11:06 AM, "sconeman" <schoen@bu.edu> wrote:
>>
>>
>> Hello,
>>
>> I'm trying to set up git on a NetApp drive at my school, BU. The NetApp
>> shares are configured with Windows permissions, and I forget the specifics
>> (which I can figure out if needed) about why this is the case, but basically
>> the deal is that if true UNIX permissions were to be used, Windows wouldn't
>> be able to read the drive. As such, and because we use the Kerberos
>> ticketing system, the permissions for the drive are set up such that the
>> owners (myself and my team members) have full permissions, but nobody else
>> does. Git doesn't like this and won't even create a bare repository. Is
>> there any way I can get git to ignore permissions and just do what it needs
>> to do?
>>
>> Thanks in advance for the help!
>>
>> -Matt
> --
On Wed, Nov 11, 2009 at 4:34 PM, Eugene Sajine <euguess@gmail.com> wrote:
> Hi,
>
> I had almost similar issue - bare repos in my case should be set up under
> user which only few guys are having password from. So what I did is just a
> small program which creates the bare repo locally and makes secure copy to
> this user home. All authentication is hidden from the end user. Then users
> can access their repos via git protocol. Ialso fillthe repo with some
> additional info for cgit.
>
> Eugene
BTW I'm using "git clone --bare" in this process, so if you have a
repo with working copy you can create a bare one separately, put it on
the server and then connect to it via "git remote add"
Eugene
^ 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