* 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: [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: 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: 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: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: 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
* [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: 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
* 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
* 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
* [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
* 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
* 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: [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
* 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: 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
* 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
* git status internals and line endings
From: Marc Strapetz @ 2009-11-12 20:32 UTC (permalink / raw)
To: git
I'm trying to figure out under which circumstances changes in line
endings are resulting in 'modified' status (resp. will be committed). I
have three files with the same content, differing only in line endings:
- file1 is committed with CRLF and has LF in working tree
- file2 is committed with CRLF and has CRLF in working tree
- file3 is committed with LF and has CRLF in working tree
On Linux, file1 and file3 are reported as modified -- as I would expect.
The surprise is on Windows: here only file1 is reported as modified. Why
not file3? Btw, 'git hash-object file3' reports the same SHA as for the
LF-only content in the repository (not so on Linux, as expected).
Is this some special handling on Windows (and possibly on Mac OS)? In
this case, can someone please point me to the corresponding code part?
Thanks for any comments regarding this topic.
--
Best regards,
Marc Strapetz
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
^ permalink raw reply
* Re: get git not to care about permissions
From: Matt Schoen @ 2009-11-12 21:44 UTC (permalink / raw)
To: Thomas Rast; +Cc: Jay Soffian, git, euguess
In-Reply-To: <200911121710.44314.trast@student.ethz.ch>
On Thu, Nov 12, 2009 at 11:10 AM, Thomas Rast <trast@student.ethz.ch> wrote:
> 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...
I'm pretty sure I can. How can I test this? I can ls all
subdirectories within the path, and when I navigate to the path, I
usually do it absolutely. After all, this is a network share, so I
have to start with "/ad/eng/...". Although, this is curious. Some of
the directories show "d---------" when I do ls -al. They were created
by root in the same environment (forced 700), but I can still read
their contents, and such.
Does open() strictly require the permissions you give it? Like I
mentioned, the permissions are locked at 700. Even if I try to chmod
777 the directory, I see no error, but the permissions remain
unchanged. I'm thinking of doing a custom compile, removing those
places where specific permissions are needed. My fear is that those
places are many...
^ permalink raw reply
* Re: Git in next is broken
From: René Scharfe @ 2009-11-12 22:17 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, Julian Phillips
In-Reply-To: <alpine.LFD.2.00.0911121513470.16711@xanadu.home>
Nicolas Pitre schrieb:
> 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
Can't reproduce because I don't know how to create duplicate refs, but does
the following help?
remote.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/remote.c b/remote.c
index 4f9f0cc..10cc985 100644
--- a/remote.c
+++ b/remote.c
@@ -754,6 +754,8 @@ void ref_remove_duplicates(struct ref *ref_map)
prev->next = ref_map->next;
free(ref_map->peer_ref);
free(ref_map);
+ ref_map = next;
+ continue;
}
item = string_list_insert(ref_map->peer_ref->name, &refs);
^ permalink raw reply related
* Re: Git in next is broken
From: Julian Phillips @ 2009-11-12 22:45 UTC (permalink / raw)
To: René Scharfe; +Cc: Nicolas Pitre, git
In-Reply-To: <4AFC8960.9090808@lsrfire.ath.cx>
On Thu, 12 Nov 2009, Ren? Scharfe wrote:
> Nicolas Pitre schrieb:
>> 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
>
> Can't reproduce because I don't know how to create duplicate refs, but does
> the following help?
>
>
> remote.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/remote.c b/remote.c
> index 4f9f0cc..10cc985 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -754,6 +754,8 @@ void ref_remove_duplicates(struct ref *ref_map)
> prev->next = ref_map->next;
> free(ref_map->peer_ref);
> free(ref_map);
> + ref_map = next;
You don't need this line (this is taken care of in the for(...)).
> + continue;
Ack. This one however, you do need. Good catch.
> }
>
> item = string_list_insert(ref_map->peer_ref->name, &refs);
>
--
Julian
---
Punishment becomes ineffective after a certain point. Men become insensitive.
-- Eneg, "Patterns of Force", stardate 2534.7
^ permalink raw reply
* [PATCH 2/2] git-svn: handle SVN merges from revisions past the tip of the branch
From: Toby Allsopp @ 2009-11-12 20:18 UTC (permalink / raw)
To: git; +Cc: Sam Vilain, Eric Wong
When recording the revisions that it has merged, SVN sets the top
revision to be the latest revision in the repository, which is not
necessarily a revision on the branch that is being merged from. When
it is not on the branch, git-svn fails to add the extra parent to
represent the merge because it relies on finding the commit on the
branch that corresponds to the top of the SVN merge range.
In order to correctly handle this case, we look for the maximum
revision less than or equal to the top of the SVN merge range that is
actually on the branch being merged from.
Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz>
---
git-svn.perl | 7 +++++--
t/t9151-svn-mergeinfo.sh | 2 +-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 6a3b501..27fbe30 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2950,8 +2950,11 @@ sub find_extra_svn_parents {
my $bottom_commit =
$gs->rev_map_get($bottom, $self->ra_uuid) ||
$gs->rev_map_get($bottom+1, $self->ra_uuid);
- my $top_commit =
- $gs->rev_map_get($top, $self->ra_uuid);
+ my $top_commit;
+ for (; !$top_commit && $top >= $bottom; --$top) {
+ $top_commit =
+ $gs->rev_map_get($top, $self->ra_uuid);
+ }
unless ($top_commit and $bottom_commit) {
warn "W:unknown path/rev in svn:mergeinfo "
diff --git a/t/t9151-svn-mergeinfo.sh b/t/t9151-svn-mergeinfo.sh
index 0d42c84..f57daf4 100755
--- a/t/t9151-svn-mergeinfo.sh
+++ b/t/t9151-svn-mergeinfo.sh
@@ -19,7 +19,7 @@ test_expect_success 'represent svn merges without intervening commits' "
[ `git cat-file commit HEAD^1 | grep parent | wc -l` -eq 2 ]
"
-test_expect_failure 'represent svn merges with intervening commits' "
+test_expect_success 'represent svn merges with intervening commits' "
[ `git cat-file commit HEAD | grep parent | wc -l` -eq 2 ]
"
--
1.6.5.2.155.gbb47.dirty
^ permalink raw reply related
* [PATCH 1/2] git-svn: add (failing) test for SVN 1.5+ merge with intervening commit
From: Toby Allsopp @ 2009-11-12 20:48 UTC (permalink / raw)
To: git; +Cc: Sam Vilain, Eric Wong
This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo
properties. The problematic case is when there is some commit on an
unrelated branch after the last commit on the merged-from branch.
When SVN records the mergeinfo property, it records the latest
revision in the whole repository, which, in the problematic case, is
not on the branch it is merging from.
To trigger the git-svn bug, we modify t9151 to include two SVN merges,
the second of which has an intervening commit. The SVN dump was
generated using SVN 1.6.6 (on Debian squeeze amd64).
Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz>
---
t/t9151-svn-mergeinfo.sh | 6 +-
t/t9151/make-svnmerge-dump | 32 ++++-
t/t9151/svn-mergeinfo.dump | 386 +++++++++++++++++++++++++++++++++++++-------
3 files changed, 366 insertions(+), 58 deletions(-)
diff --git a/t/t9151-svn-mergeinfo.sh b/t/t9151-svn-mergeinfo.sh
index 9bee516..0d42c84 100755
--- a/t/t9151-svn-mergeinfo.sh
+++ b/t/t9151-svn-mergeinfo.sh
@@ -15,7 +15,11 @@ test_expect_success 'load svn dump' "
git svn fetch --all
"
-test_expect_success 'svn merges were represented coming in' "
+test_expect_success 'represent svn merges without intervening commits' "
+ [ `git cat-file commit HEAD^1 | grep parent | wc -l` -eq 2 ]
+ "
+
+test_expect_failure 'represent svn merges with intervening commits' "
[ `git cat-file commit HEAD | grep parent | wc -l` -eq 2 ]
"
diff --git a/t/t9151/make-svnmerge-dump b/t/t9151/make-svnmerge-dump
index e35d64d..7e3da75 100644
--- a/t/t9151/make-svnmerge-dump
+++ b/t/t9151/make-svnmerge-dump
@@ -28,6 +28,10 @@ svn cp trunk branches/left
echo "Committing BRANCH POINT"
svn commit -m "make left branch"
+svn cp trunk branches/right
+
+echo "Committing other BRANCH POINT"
+svn commit -m "make right branch"
cd branches/left/
#$sm init
@@ -64,7 +68,33 @@ git cat-file blob b51ad431:Makefile > Makefile
svn resolved Makefile
-svn commit -m "Merge trunk"
+svn commit -m "Merge trunk 1"
+
+# create commits on both branches
+
+cd ../branches/left
+git cat-file blob ff5ebe39:Makefile > Makefile
+echo "Committing BRANCH UPDATE 4"
+svn commit -m "left update 4"
+
+cd ../right
+git cat-file blob b5039db6:Makefile > Makefile
+echo "Committing other BRANCH UPDATE 1"
+svn commit -m "right update 1"
+
+# merge to trun again
+
+cd ../..
+svn update
+cd trunk
+
+svn merge ../branches/left --accept postpone
+
+git cat-file blob b51ad431:Makefile > Makefile
+
+svn resolved Makefile
+
+svn commit -m "Merge trunk 2"
cd ../..
diff --git a/t/t9151/svn-mergeinfo.dump b/t/t9151/svn-mergeinfo.dump
index 2153187..11a883f 100644
--- a/t/t9151/svn-mergeinfo.dump
+++ b/t/t9151/svn-mergeinfo.dump
@@ -1,6 +1,6 @@
SVN-fs-dump-format-version: 2
-UUID: 1ce241d1-ba54-4eb9-bded-03057fe48a33
+UUID: 1530d5a2-a1dc-4438-8ad5-d95e96db8945
Revision-number: 0
Prop-content-length: 56
@@ -9,12 +9,12 @@ Content-length: 56
K 8
svn:date
V 27
-2009-10-20T01:33:37.692723Z
+2009-11-12T20:29:38.812226Z
PROPS-END
Revision-number: 1
-Prop-content-length: 123
-Content-length: 123
+Prop-content-length: 127
+Content-length: 127
K 7
svn:log
@@ -22,12 +22,12 @@ V 24
Setup trunk and branches
K 10
svn:author
-V 4
-samv
+V 8
+tallsopp
K 8
svn:date
V 27
-2009-10-20T01:33:38.159933Z
+2009-11-12T20:29:39.045856Z
PROPS-END
Node-path: branches
@@ -49,8 +49,8 @@ PROPS-END
Revision-number: 2
-Prop-content-length: 106
-Content-length: 106
+Prop-content-length: 110
+Content-length: 110
K 7
svn:log
@@ -58,12 +58,12 @@ V 8
ancestor
K 10
svn:author
-V 4
-samv
+V 8
+tallsopp
K 8
svn:date
V 27
-2009-10-20T01:33:39.160059Z
+2009-11-12T20:29:40.079587Z
PROPS-END
Node-path: trunk/Makefile
@@ -72,6 +72,7 @@ Node-action: add
Prop-content-length: 10
Text-content-length: 2401
Text-content-md5: bfd8ff778d1492dc6758567373176a89
+Text-content-sha1: 103205ce331f7d64086dba497574734f78439590
Content-length: 2411
PROPS-END
@@ -155,8 +156,8 @@ backup: clean
Revision-number: 3
-Prop-content-length: 115
-Content-length: 115
+Prop-content-length: 119
+Content-length: 119
K 7
svn:log
@@ -164,12 +165,12 @@ V 16
make left branch
K 10
svn:author
-V 4
-samv
+V 8
+tallsopp
K 8
svn:date
V 27
-2009-10-20T01:33:41.148192Z
+2009-11-12T20:29:42.084439Z
PROPS-END
Node-path: branches/left
@@ -177,27 +178,54 @@ Node-kind: dir
Node-action: add
Node-copyfrom-rev: 1
Node-copyfrom-path: trunk
-Prop-content-length: 34
-Content-length: 34
-K 13
-svn:mergeinfo
-V 0
+Node-path: branches/left/Makefile
+Node-kind: file
+Node-action: add
+Node-copyfrom-rev: 2
+Node-copyfrom-path: trunk/Makefile
+Text-copy-source-md5: bfd8ff778d1492dc6758567373176a89
+Text-copy-source-sha1: 103205ce331f7d64086dba497574734f78439590
+
+
+Revision-number: 4
+Prop-content-length: 120
+Content-length: 120
+
+K 7
+svn:log
+V 17
+make right branch
+K 10
+svn:author
+V 8
+tallsopp
+K 8
+svn:date
+V 27
+2009-11-12T20:29:44.065452Z
PROPS-END
+Node-path: branches/right
+Node-kind: dir
+Node-action: add
+Node-copyfrom-rev: 1
+Node-copyfrom-path: trunk
+
-Node-path: branches/left/Makefile
+Node-path: branches/right/Makefile
Node-kind: file
Node-action: add
Node-copyfrom-rev: 2
Node-copyfrom-path: trunk/Makefile
Text-copy-source-md5: bfd8ff778d1492dc6758567373176a89
+Text-copy-source-sha1: 103205ce331f7d64086dba497574734f78439590
-Revision-number: 4
-Prop-content-length: 112
-Content-length: 112
+Revision-number: 5
+Prop-content-length: 116
+Content-length: 116
K 7
svn:log
@@ -205,12 +233,12 @@ V 13
left update 1
K 10
svn:author
-V 4
-samv
+V 8
+tallsopp
K 8
svn:date
V 27
-2009-10-20T01:33:42.148773Z
+2009-11-12T20:29:45.066262Z
PROPS-END
Node-path: branches/left/Makefile
@@ -218,6 +246,7 @@ Node-kind: file
Node-action: change
Text-content-length: 2465
Text-content-md5: 16e38d9753b061731650561ce01b1195
+Text-content-sha1: 36da4b84ea9b64218ab48171dfc5c48ae025f38b
Content-length: 2465
# -DCOLLISION_CHECK if you believe that SHA1's
@@ -299,9 +328,9 @@ backup: clean
cd .. ; tar czvf dircache.tar.gz dir-cache
-Revision-number: 5
-Prop-content-length: 111
-Content-length: 111
+Revision-number: 6
+Prop-content-length: 115
+Content-length: 115
K 7
svn:log
@@ -309,12 +338,12 @@ V 12
trunk update
K 10
svn:author
-V 4
-samv
+V 8
+tallsopp
K 8
svn:date
V 27
-2009-10-20T01:33:43.159959Z
+2009-11-12T20:29:46.278498Z
PROPS-END
Node-path: trunk/Makefile
@@ -322,6 +351,7 @@ Node-kind: file
Node-action: change
Text-content-length: 2521
Text-content-md5: 0668418a621333f4aa8b6632cd63e2a0
+Text-content-sha1: 4f29afd038e52f45acb5ef8c41acfc70062a741a
Content-length: 2521
# -DCOLLISION_CHECK if you believe that SHA1's
@@ -406,9 +436,9 @@ backup: clean
cd .. ; tar czvf dircache.tar.gz dir-cache
-Revision-number: 6
-Prop-content-length: 112
-Content-length: 112
+Revision-number: 7
+Prop-content-length: 116
+Content-length: 116
K 7
svn:log
@@ -416,12 +446,12 @@ V 13
left update 2
K 10
svn:author
-V 4
-samv
+V 8
+tallsopp
K 8
svn:date
V 27
-2009-10-20T01:33:44.164175Z
+2009-11-12T20:29:47.069090Z
PROPS-END
Node-path: branches/left/Makefile
@@ -429,6 +459,7 @@ Node-kind: file
Node-action: change
Text-content-length: 2529
Text-content-md5: f6b197cc3f2e89a83e545d4bb003de73
+Text-content-sha1: 2f656677cfec0bceec85e53036ffb63e25126f8e
Content-length: 2529
# -DCOLLISION_CHECK if you believe that SHA1's
@@ -510,9 +541,9 @@ backup: clean
cd .. ; tar czvf dircache.tar.gz dir-cache
-Revision-number: 7
-Prop-content-length: 112
-Content-length: 112
+Revision-number: 8
+Prop-content-length: 116
+Content-length: 116
K 7
svn:log
@@ -520,12 +551,12 @@ V 13
left update 3
K 10
svn:author
-V 4
-samv
+V 8
+tallsopp
K 8
svn:date
V 27
-2009-10-20T01:33:45.144214Z
+2009-11-12T20:29:48.053835Z
PROPS-END
Node-path: branches/left/Makefile
@@ -533,6 +564,7 @@ Node-kind: file
Node-action: change
Text-content-length: 2593
Text-content-md5: 5ccff689fb290e00b85fe18ee50c54ba
+Text-content-sha1: a13de8e23f1483efca3e57b2b64b0ae6f740ce10
Content-length: 2593
# -DCOLLISION_CHECK if you believe that SHA1's
@@ -614,22 +646,22 @@ backup: clean
cd .. ; tar czvf dircache.tar.gz dir-cache
-Revision-number: 8
-Prop-content-length: 110
-Content-length: 110
+Revision-number: 9
+Prop-content-length: 116
+Content-length: 116
K 7
svn:log
-V 11
-Merge trunk
+V 13
+Merge trunk 1
K 10
svn:author
-V 4
-samv
+V 8
+tallsopp
K 8
svn:date
V 27
-2009-10-20T01:33:48.176135Z
+2009-11-12T20:29:51.098306Z
PROPS-END
Node-path: trunk
@@ -641,7 +673,7 @@ Content-length: 53
K 13
svn:mergeinfo
V 18
-/branches/left:2-7
+/branches/left:2-8
PROPS-END
@@ -650,6 +682,7 @@ Node-kind: file
Node-action: change
Text-content-length: 2713
Text-content-md5: 0afbe34f244cd662b1f97d708c687f90
+Text-content-sha1: 46d9377d783e67a9b581da110352e799517c8a14
Content-length: 2713
# -DCOLLISION_CHECK if you believe that SHA1's
@@ -734,3 +767,244 @@ backup: clean
cd .. ; tar czvf dircache.tar.gz dir-cache
+Revision-number: 10
+Prop-content-length: 116
+Content-length: 116
+
+K 7
+svn:log
+V 13
+left update 4
+K 10
+svn:author
+V 8
+tallsopp
+K 8
+svn:date
+V 27
+2009-11-12T20:29:52.081644Z
+PROPS-END
+
+Node-path: branches/left/Makefile
+Node-kind: file
+Node-action: change
+Text-content-length: 2529
+Text-content-md5: f6b197cc3f2e89a83e545d4bb003de73
+Text-content-sha1: 2f656677cfec0bceec85e53036ffb63e25126f8e
+Content-length: 2529
+
+# -DCOLLISION_CHECK if you believe that SHA1's
+# 1461501637330902918203684832716283019655932542976 hashes do not give you
+# enough guarantees about no collisions between objects ever hapenning.
+#
+# -DNSEC if you want git to care about sub-second file mtimes and ctimes.
+# Note that you need some new glibc (at least >2.2.4) for this, and it will
+# BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely randomly
+# break unless your underlying filesystem supports those sub-second times
+# (my ext3 doesn't).
+CFLAGS=-g -O3 -Wall
+
+CC=gcc
+
+
+PROG= update-cache show-diff init-db write-tree read-tree commit-tree \
+ cat-file fsck-cache checkout-cache diff-tree rev-tree show-files \
+ check-files ls-tree merge-base
+
+all: $(PROG)
+
+install: $(PROG)
+ install $(PROG) $(HOME)/bin/
+
+LIBS= -lssl -lz
+
+init-db: init-db.o
+
+update-cache: update-cache.o read-cache.o
+ $(CC) $(CFLAGS) -o update-cache update-cache.o read-cache.o $(LIBS)
+
+show-diff: show-diff.o read-cache.o
+ $(CC) $(CFLAGS) -o show-diff show-diff.o read-cache.o $(LIBS)
+
+write-tree: write-tree.o read-cache.o
+ $(CC) $(CFLAGS) -o write-tree write-tree.o read-cache.o $(LIBS)
+
+read-tree: read-tree.o read-cache.o
+ $(CC) $(CFLAGS) -o read-tree read-tree.o read-cache.o $(LIBS)
+
+commit-tree: commit-tree.o read-cache.o
+ $(CC) $(CFLAGS) -o commit-tree commit-tree.o read-cache.o $(LIBS)
+
+cat-file: cat-file.o read-cache.o
+ $(CC) $(CFLAGS) -o cat-file cat-file.o read-cache.o $(LIBS)
+
+fsck-cache: fsck-cache.o read-cache.o object.o commit.o tree.o blob.o
+ $(CC) $(CFLAGS) -o fsck-cache fsck-cache.o read-cache.o object.o commit.o tree.o blob.o $(LIBS)
+
+checkout-cache: checkout-cache.o read-cache.o
+ $(CC) $(CFLAGS) -o checkout-cache checkout-cache.o read-cache.o $(LIBS)
+
+diff-tree: diff-tree.o read-cache.o
+ $(CC) $(CFLAGS) -o diff-tree diff-tree.o read-cache.o $(LIBS)
+
+rev-tree: rev-tree.o read-cache.o object.o commit.o tree.o blob.o
+ $(CC) $(CFLAGS) -o rev-tree rev-tree.o read-cache.o object.o commit.o tree.o blob.o $(LIBS)
+
+show-files: show-files.o read-cache.o
+ $(CC) $(CFLAGS) -o show-files show-files.o read-cache.o $(LIBS)
+
+check-files: check-files.o read-cache.o
+ $(CC) $(CFLAGS) -o check-files check-files.o read-cache.o $(LIBS)
+
+ls-tree: ls-tree.o read-cache.o
+ $(CC) $(CFLAGS) -o ls-tree ls-tree.o read-cache.o $(LIBS)
+
+merge-base: merge-base.o read-cache.o
+ $(CC) $(CFLAGS) -o merge-base merge-base.o read-cache.o $(LIBS)
+
+read-cache.o: cache.h
+show-diff.o: cache.h
+
+clean:
+ rm -f *.o $(PROG)
+
+backup: clean
+ cd .. ; tar czvf dircache.tar.gz dir-cache
+
+
+Revision-number: 11
+Prop-content-length: 117
+Content-length: 117
+
+K 7
+svn:log
+V 14
+right update 1
+K 10
+svn:author
+V 8
+tallsopp
+K 8
+svn:date
+V 27
+2009-11-12T20:29:53.059636Z
+PROPS-END
+
+Node-path: branches/right/Makefile
+Node-kind: file
+Node-action: change
+Text-content-length: 2593
+Text-content-md5: 5ccff689fb290e00b85fe18ee50c54ba
+Text-content-sha1: a13de8e23f1483efca3e57b2b64b0ae6f740ce10
+Content-length: 2593
+
+# -DCOLLISION_CHECK if you believe that SHA1's
+# 1461501637330902918203684832716283019655932542976 hashes do not give you
+# enough guarantees about no collisions between objects ever hapenning.
+#
+# -DNSEC if you want git to care about sub-second file mtimes and ctimes.
+# Note that you need some new glibc (at least >2.2.4) for this, and it will
+# BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely randomly
+# break unless your underlying filesystem supports those sub-second times
+# (my ext3 doesn't).
+CFLAGS=-g -O3 -Wall
+
+CC=gcc
+
+
+PROG= update-cache show-diff init-db write-tree read-tree commit-tree \
+ cat-file fsck-cache checkout-cache diff-tree rev-tree show-files \
+ check-files ls-tree merge-base
+
+all: $(PROG)
+
+install: $(PROG)
+ install $(PROG) $(HOME)/bin/
+
+LIBS= -lssl -lz
+
+init-db: init-db.o
+
+update-cache: update-cache.o read-cache.o
+ $(CC) $(CFLAGS) -o update-cache update-cache.o read-cache.o $(LIBS)
+
+show-diff: show-diff.o read-cache.o
+ $(CC) $(CFLAGS) -o show-diff show-diff.o read-cache.o $(LIBS)
+
+write-tree: write-tree.o read-cache.o
+ $(CC) $(CFLAGS) -o write-tree write-tree.o read-cache.o $(LIBS)
+
+read-tree: read-tree.o read-cache.o
+ $(CC) $(CFLAGS) -o read-tree read-tree.o read-cache.o $(LIBS)
+
+commit-tree: commit-tree.o read-cache.o
+ $(CC) $(CFLAGS) -o commit-tree commit-tree.o read-cache.o $(LIBS)
+
+cat-file: cat-file.o read-cache.o
+ $(CC) $(CFLAGS) -o cat-file cat-file.o read-cache.o $(LIBS)
+
+fsck-cache: fsck-cache.o read-cache.o object.o commit.o tree.o blob.o
+ $(CC) $(CFLAGS) -o fsck-cache fsck-cache.o read-cache.o object.o commit.o tree.o blob.o $(LIBS)
+
+checkout-cache: checkout-cache.o read-cache.o
+ $(CC) $(CFLAGS) -o checkout-cache checkout-cache.o read-cache.o $(LIBS)
+
+diff-tree: diff-tree.o read-cache.o
+ $(CC) $(CFLAGS) -o diff-tree diff-tree.o read-cache.o $(LIBS)
+
+rev-tree: rev-tree.o read-cache.o object.o commit.o tree.o blob.o
+ $(CC) $(CFLAGS) -o rev-tree rev-tree.o read-cache.o object.o commit.o tree.o blob.o $(LIBS)
+
+show-files: show-files.o read-cache.o
+ $(CC) $(CFLAGS) -o show-files show-files.o read-cache.o $(LIBS)
+
+check-files: check-files.o read-cache.o
+ $(CC) $(CFLAGS) -o check-files check-files.o read-cache.o $(LIBS)
+
+ls-tree: ls-tree.o read-cache.o
+ $(CC) $(CFLAGS) -o ls-tree ls-tree.o read-cache.o $(LIBS)
+
+merge-base: merge-base.o read-cache.o object.o commit.o tree.o blob.o
+ $(CC) $(CFLAGS) -o merge-base merge-base.o read-cache.o object.o commit.o tree.o blob.o $(LIBS)
+
+read-cache.o: cache.h
+show-diff.o: cache.h
+
+clean:
+ rm -f *.o $(PROG)
+
+backup: clean
+ cd .. ; tar czvf dircache.tar.gz dir-cache
+
+
+Revision-number: 12
+Prop-content-length: 116
+Content-length: 116
+
+K 7
+svn:log
+V 13
+Merge trunk 2
+K 10
+svn:author
+V 8
+tallsopp
+K 8
+svn:date
+V 27
+2009-11-12T20:29:56.083003Z
+PROPS-END
+
+Node-path: trunk
+Node-kind: dir
+Node-action: change
+Prop-content-length: 54
+Content-length: 54
+
+K 13
+svn:mergeinfo
+V 19
+/branches/left:2-11
+PROPS-END
+
+
--
1.6.5.2.155.gbb47.dirty
^ permalink raw reply related
* Re: git status internals and line endings
From: Jeff King @ 2009-11-13 0:15 UTC (permalink / raw)
To: Marc Strapetz; +Cc: git
In-Reply-To: <4AFC70CE.5020106@syntevo.com>
On Thu, Nov 12, 2009 at 09:32:14PM +0100, Marc Strapetz wrote:
> On Linux, file1 and file3 are reported as modified -- as I would expect.
> The surprise is on Windows: here only file1 is reported as modified. Why
> not file3? Btw, 'git hash-object file3' reports the same SHA as for the
> LF-only content in the repository (not so on Linux, as expected).
>
> Is this some special handling on Windows (and possibly on Mac OS)? In
> this case, can someone please point me to the corresponding code part?
> Thanks for any comments regarding this topic.
Sounds like the core.autocrlf setting (see "git help config"), which I
believe is set by default on Windows.
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] git-svn: handle SVN merges from revisions past the tip of the branch
From: Sam Vilain @ 2009-11-13 0:47 UTC (permalink / raw)
To: Toby Allsopp; +Cc: git, Eric Wong
In-Reply-To: <871vk35o86.fsf@navakl084.mitacad.com>
Toby Allsopp wrote:
> When recording the revisions that it has merged, SVN sets the top
> revision to be the latest revision in the repository, which is not
> necessarily a revision on the branch that is being merged from. When
> it is not on the branch, git-svn fails to add the extra parent to
> represent the merge because it relies on finding the commit on the
> branch that corresponds to the top of the SVN merge range.
I thought, "that sounds like he's repeating himself, wait a sec..."
> -test_expect_failure 'represent svn merges with intervening commits' "
> +test_expect_success 'represent svn merges with intervening commits' "
> [ `git cat-file commit HEAD | grep parent | wc -l` -eq 2 ]
> "
So you made a failing test and then added the implementation for it?
Interesting strategy :). I'd probably not repeat the same sentence
twice though.
Thanks for contributing this. There might be other bugs too, especially
when upstream has a more complicated merge hierarchy ... apparently svn
tends to get it wrong, so checking for all commits might not work in
that case.
It would be nice if "dcommit" could make these commits, too...
Sam
^ 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