* Re: why '--init' in git-submodule update
From: Francis Moreau @ 2012-11-07 7:10 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git
In-Reply-To: <20121105213004.GA2797@book.hvoigt.net>
Hi,
On Mon, Nov 5, 2012 at 10:30 PM, Heiko Voigt <hvoigt@hvoigt.net> wrote:
> Hi,
>
> On Mon, Nov 05, 2012 at 05:30:51PM +0100, Francis Moreau wrote:
>> I'm wondering why the --init option from git-submodule-update is not
>> at least the defaut. Or even wilder, why this option exists at all and
>> git-submodule-update always behave like --init was always passed.
>
> That was a design decision. People may not be interested in all
> submodules but just a subset they are working with. E.g. think of a
> large media directory as a submodule the developers might not be
> interested in having it around all the time because only the designers
> are heavily working with it.
>
Thanks for explaining.
Another possible solution was to check if one or several submodules
are already checkout. If so then update only them. If none of them is
checkout then assume --init is passed and init all of them. Same if a
path is passed and this path corresponds to a submodule not checkout
yet.
--
Francis
^ permalink raw reply
* Bug? Subtree merge seems to choke on trailing slashes.
From: Jack O'Connor @ 2012-11-07 1:58 UTC (permalink / raw)
To: git
I'm summarizing from here:
http://stackoverflow.com/questions/5904256/git-subtree-merge-into-a-deeply-nested-subdirectory
Quick repro:
1) I do an initial subtree merge in what I think is the standard way
(http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html).
My prefix is simply "test/".
2) I try to merge more upstream changes on top of that with the
following command:
git merge --strategy-option=subtree='test/' $upstream_stuff
3) Git fails with an obscure error:
fatal: entry not found in tree daf4d0f0a20b8b6ec007be9fcafeac84a6eba4f0
If I remove the trailing slash from the command in step 2, it works just fine:
git merge --strategy-option=subtree='test' $upstream_stuff
Note in the error message above, there's a double space after "entry".
Is it looking for a tree with an empty name? Did my trailing slash
imply a directory named empty-string?
Thanks for your help.
-- Jack O'Connor
^ permalink raw reply
* Re: Support for a series of patches, i.e. patchset or changeset?
From: Eric Miao @ 2012-11-07 1:50 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Michael J Gruber, git
In-Reply-To: <5098BFC0.6040709@viscovery.net>
On Tue, Nov 6, 2012 at 3:44 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Am 11/6/2012 7:56, schrieb Eric Miao:
>> On Tue, Nov 6, 2012 at 2:39 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>>> Am 11/6/2012 1:58, schrieb Eric Miao:
>>>> E.g. when we merged a series of patches:
>>>>
>>>> [PATCH 00/08]
>>>> [PATCH 01/08]
>>>> ...
>>>> [PATCH 08/08]
>>>>
>>>> How do we know this whole series after merged when only one of these
>>>> commits are known?
>>>
>>> You can use git name-rev. For example:
>>>
>>> $ git name-rev 9284bdae3
>>> 9284bdae3 remotes/origin/pu~2^2~7
>>>
>>> This tell you that the series was merged two commits before origin/pu, and
>>> then it is the 7th from the tip of the series. Now you can
>>>
>>> $ git log origin/pu~2^..origin/pu~2^2
>>>
>>> to see the whole series.
>>
>> I'm just curious how this is implemented in git, are we keeping the info
>> of the series that's applied in a whole?
>
> If the maintainer did his job well, then everything that you had in [PATCH
> 01/08] ... [PATCH 08/08] is in the commits of the series, and [PATCH
> 00/08] (the cover letter) is in the commit that merged the series.
>
> Anything else that I didn't mention but you consider as "the info of the
> series"?
>
>> But this still looks like be inferred basing on a branch head, and I'm
>> afraid this may not be applicable in every case.
>
> What's the problem? That it's inferred? Or that it needs a branch head?
Take kernel development for example, sub-maintainers not always keep
a patchset in a single branch, instead, there could be a mix of patchset
and single fixing patches on a same branch:
---A1---A2---A3---B---C---D---E1---E2---E3---E4---F---G---H---> branch
When we identify a specific patch, e.g. E3, is it possible to figure out
the whole patchset of E<n>?
>
> -- Hannes
^ permalink raw reply
* Re: Rebasing published branches?
From: Antony Male @ 2012-11-06 23:14 UTC (permalink / raw)
To: Josef Wolf, git
In-Reply-To: <20121106201822.GE28437@raven.wolf.lan>
On 06/11/2012 8:18 pm, Josef Wolf wrote:
> Hello,
>
> I know, I should never rebase published branches. But...
The major trouble with making rewritten branches public is one of merges.
Assume I have two local repos, A and B, sharing a single remote. I
create a branch in A, push it to the remote, then fetch it into B. I
then re-write the branch in A and force-push it, and fetch from B.
As far as B is now concerned, its local history diverges from the
remote's -- a scenario which must be resolved, usually through a merge,
before any work can be pushed. Unfortunately, this merge merges together
the two versions of history -- the old one from B's local history, and
the new one from the remote -- leading to a mess. If B then pushes, this
mess is published.
So "published", in the "don't rewrite published branches" sense, means
"a branch which someone else might regularly pull from, and in doing so
merge together two versions of history".
In general, remembering that you've pushed rewritten history, and to
makes sure that you haven't merged two versions of history after a
merge/pull, is sufficient. After rewriting history on a remote, rebase /
pull --rebase on a local, un-rewritten branch is sufficient to avoid the
merging-two-versions-of-history nightmare.
See "RECOVERING FROM UPSTREAM REBASE" in man git-rebase for a more
in-depth explanation and more discussion of solutions.
> I frequently work on different computers and would like to share my private
> branches across them. When done and the feature is in a good shape, I'd like
> to rebase to clean up history before I make it available to other people.
Rebasing a branch which is about to be deleted (after merging,
presumably) is generally regarded as fine, provided you're not expecting
people to base work on the branch before it's rewritten.
Antony
^ permalink raw reply
* Re: Rebasing published branches?
From: Andrew Ardill @ 2012-11-06 22:53 UTC (permalink / raw)
To: Josef Wolf, git@vger.kernel.org
In-Reply-To: <20121106201822.GE28437@raven.wolf.lan>
Hi Josef,
On 7 November 2012 07:18, Josef Wolf <jw@raven.inka.de> wrote:
>
> Hello,
>
> I know, I should never rebase published branches. But...
>
> I frequently work on different computers and would like to share my private
> branches across them. When done and the feature is in a good shape, I'd like
> to rebase to clean up history before I make it available to other people.
>
> I guess rebasing such branches would be OK as long as I can reliably remember
> to delete those branches on _all_ the clones I ever created.
>
> But waht if I ever make a mistake? How would one recover from such rebase
> disasters? Anybody knows a good description how such a recover would be done?
The only real problem you should encounter is not knowing which
repository holds the 'true' feature branch, that is the one which you
want to publish.
The reason why rebasing public branches (where 'public' means somebody
_else_ is tracking your branch) is bad is that you are rewriting
somebody else's history. This can cause headache and pain for them if
they have based work off what you have already published.
In your situation, you are the only one working on these feature
branches, and you know that you plan to rebase them. There is little
risk of you rewriting someone else's history, and even if you did it
is clear that these branches were always meant to be rebased so you
should surprise anyone.
As a practical note, you'll probably find it easier to keep track of
the current state of your feature if you use one repository as your
own 'blessed' repository. After working on a clone somewhere, always
push to the blessed repository, and sync from it before you start
work. This way you will always have the correct version of your
feature branch.
If worse comes to worse (somehow) remember that rebasing does not
delete the old commits, just recreates them and points the branch at
the recreated versions. The old versions of these commits should be
available in the reflog, at least for a few weeks after the rebase.
Regards,
Andrew Ardill
^ permalink raw reply
* Re: What about SHA-1 collisions?
From: Josef Wolf @ 2012-11-06 22:09 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20121106T223000-502@post.gmane.org>
On Tue, Nov 06, 2012 at 09:41:29PM +0000, John McKown wrote:
> Josef Wolf <jw <at> raven.inka.de> writes:
> > Just for curiosity: what would happen if such a collision would occur within
> > one repository?
> In a sense, this cannot happen.
In the scenario you described, contents of this version of file "b" are lost
and replaced by the contents of file "a". So file "b" is broken.
What happens when files "a" and "b" are added into different repositories?
File "a" is added to repos "A", and file "b" is added to repos "B". Now it
depends from which repository you fetch the collided blob first. If you fetch
it from "A", file "b" will be broken. If you fetch first from "B", your "a"
will be broken.
It becomes even more interesting, if some commit or tree object would have
the same SHA1 as some other object. I guess, in such a case the repository
would be completely hosed?
^ permalink raw reply
* Re: What about SHA-1 collisions?
From: John McKown @ 2012-11-06 21:41 UTC (permalink / raw)
To: git
In-Reply-To: <20121106202643.GF28437@raven.wolf.lan>
Josef Wolf <jw <at> raven.inka.de> writes:
>
> Hello,
>
> we all know, the probability for SHA-1 collisions is very, very low, almost
> non-existant. But we also know that they are not impossible.
>
> Just for curiosity: what would happen if such a collision would occur within
> one repository?
>
In a sense, this cannot happen. Suppose you have a new working directory.
You do a "git init" to initialize it for use by git. You then copy in a
bunch of data from elsewhere. By chance, files "a" and "b" have different
content, but the same sha1 (they collide). The "git add ." command is
basically a short cut for doing something like:
for i in *;do git add $i;done
That is, it seems to add each file, one at a time in some order. Suppose
it creates the sha1 for "a" first. It then creates the appropriate
"stuff" for file "a" in the .git subdirectory, based on the sha1 value. Now,
it gets around to processing "b". It gets the sha1 value of b and finds
that it already has an entry for that value. At that point, the "git add" thinks
"Oh, I've already processed this file. No need to do anything!" So the contents
of file "b" are not saved anywhere in git and, bottom line, that version of "b"
will not be in the git repository. Ever. Because "a" already has that SHA1 "tied
up" and it is (theoretically) never released.
I think of the SHA1 value being a unique key into a "write once" database. Once
you've added some content (a file) into the database, then the SHA1 value of
that content (file) is unmodifiable. Attempts to write another record into the
database is rejected (in a read DB, you'd get some sort of DUPLICATE KEY
response). Git considers the "duplicate key" to be just fine because it ASSUMES
that the SHA1 is unique to the first file (content) which generates it.
Hope I made sense.
John
^ permalink raw reply
* Re: git ls-files --ignored and ignored directory
From: Damien Robert @ 2012-11-06 21:24 UTC (permalink / raw)
To: git
In-Reply-To: <k7bus9$o9t$1@ger.gmane.org>
Damien Robert wrote in message <k7bus9$o9t$1@ger.gmane.org>:
> I would like to use git ls-files to show all the ignored files, including
> directory.
> Is there a way to get the behavior I'd like? Thanks!
I forgot to add that this is with version 1.8.0, I haven't tried with
current master.
$ git --version
git version 1.8.0
^ permalink raw reply
* git ls-files --ignored and ignored directory
From: Damien Robert @ 2012-11-06 21:19 UTC (permalink / raw)
To: git
I would like to use git ls-files to show all the ignored files, including
directory.
As an example of setup:
mkdir /tmp/git && cd /tmp/git
git init
mkdir a b
touch a/a
touch b/b
cat >.gitignore << EOF
a/
b/*
EOF
Then if I do:
$ git ls-files --exclude-standard --ignored --others
b/b
$ git ls-files --exclude-standard --ignored --others --directory
a/
In the first case I was expecting
a/a
b/b
and in the second case
a/
b/
Is there a way to get the behavior I'd like? Thanks!
^ permalink raw reply
* Re: Workflow for templates?
From: Josef Wolf @ 2012-11-06 21:07 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <871B6C10EBEFE342A772D1159D13208537AA184A@umechphj.easf.csd.disa.mil>
On Tue, Nov 06, 2012 at 08:21:25PM +0000, Pyeron, Jason J CTR (US) wrote:
> Maybe I lost sight of your problem. Can you give a specific example of where "it" does not work?
I guess it's _me_ who's lost. I can't figure how this is supposed to
work. Maybe you have an example?
^ permalink raw reply
* [git-svn] [bug report] Index in strange state after git svn rebase
From: Samuel Rossille @ 2012-11-06 20:37 UTC (permalink / raw)
To: git; +Cc: Samuel
Hi Everybody,
Please Cc: me, I am not subscribed
I'm encountering an issue with "git svn rebase". Included in this
email is a summary of the issue, and it is fully detailed in this
stackoverflow question:
http://stackoverflow.com/questions/13183534/why-does-git-rebase-leave-opposite-sets-of-modifications-in-the-stage-and-the
I and several other people think it's a bug, but I could not find any
reference to it in the mailing list archive.
Some people have the same issue with the same svn repository, which is
quite large.
Unfortunately I have not been able to reproduce it completely from
scratch with a new svn repository. I seems to happen only on large
repository with a lot of history, branches, and files.
Here is the summary:
*What I wanted to do:*
In a branch tracking an svn remote, fetch team's content and rebase my
commit after them.
*What I did:*
Git version: "git version 1.7.10.msysgit.1"
With a clean working copy and empty index, I typed: "git svn rebase"
*What I expected:*
Fetch a couple of commits, then a successful rebase, with at the end
an empty index, and a clean working copy.
*What actually happened:*
Fetch a couple of commits, then a successful rebase, with at the end
an index containing modification that revert my commit, and a working
copy containing the expected content ("the revert of the revert")
Please feel free to contact me directly or via the SO question for any
useful additional information.
Thanks,
Samuel Rossille
^ permalink raw reply
* What about SHA-1 collisions?
From: Josef Wolf @ 2012-11-06 20:26 UTC (permalink / raw)
To: git
Hello,
we all know, the probability for SHA-1 collisions is very, very low, almost
non-existant. But we also know that they are not impossible.
Just for curiosity: what would happen if such a collision would occur within
one repository?
^ permalink raw reply
* RE: Workflow for templates?
From: Pyeron, Jason J CTR (US) @ 2012-11-06 20:21 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <20121106195045.GD28437@raven.wolf.lan>
[-- Attachment #1: Type: text/plain, Size: 3325 bytes --]
Maybe I lost sight of your problem. Can you give a specific example of where "it" does not work?
> -----Original Message-----
> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On
> Behalf Of Josef Wolf
> Sent: Tuesday, November 06, 2012 2:51 PM
> To: git@vger.kernel.org
> Subject: Re: Workflow for templates?
>
> No suggestions on this one?
>
> On Wed, Oct 31, 2012 at 11:44:04AM +0100, Josef Wolf wrote:
> > I am somewhat unsure whether it would work this way. After all, there
> seems to
> > be an unbreakable rule with git: never rebase published branches.
> >
> > Thus, once I have published my work to other people who also need to
> work on
> > the same localizations as I do, I have no longer the option of
> rebasing to get
> > rid of the localizations and put the generic template stuff for
> upstream.
> >
> > I guess, my concern is because I have not yet fully understood the
> problems of
> > rebasing, and how to recover from them.
> >
> > Maybe I should try to explain the problem in terms of repository
> > hierarchy. Let's assume, there is this hierarchy of repositories:
> >
> > upstream: central repository, containing the generic template
> >
> > foo-site: repository for site foo. Here we have localizations for a
> specific
> > administrative entity named foo (say, google).
> > This is where clones for production are made from, and
> production
> > boxes pull from here to be kept up-to-date.
> >
> > foo-prodA: A clone of foo-site, put in production and pulling from a
> specific
> > branch on foo-site to receive released, blessed updates.
> > foo-prodB: Similar to foo-prodA, but on another box.
> >
> > foo-devA: A clone of foo-site to make development, releases, and
> whatever for
> > foo.
> > foo-devB: One more clone of foo-site, Developer B is working here.
> >
> > Then, we might have more administrative entities: bar-site, bar-
> prodA,
> > bar-prodB, bar-devA, bar-devB, for example. This might be Microsoft,
> for
> > example.
> >
> > Further, foo-devA might be the same person as bar-devA.
> >
> > So when foo-devA pulls from foo-devB, then foo-devB will create
> problems when
> > he rebases after that pull.
> >
> > I think I have some kind of misunderstanding here, but I just can't
> figure
> > what it is.
> >
> >
> > Maybe I should try to explain the problem in yet other words:
> >
> > What I am trying to achieve, is to extend the workflow from
> development to
> > deployment across multiple administrative entities. As a picture:
> >
> > upstream (templates only).
> > ^
> > |
> > v
> > development (configured, might contain experimental changes)
> > ^
> > |
> > v
> > deployment (configured)
> >
> > This workflow should not stop at administrative borders. Just replace
> foo by
> > google and bar by Microsoft to get an idea of what I am trying to
> achieve.
> > --
> > To unsubscribe from this list: send the line "unsubscribe git" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5615 bytes --]
^ permalink raw reply
* Rebasing published branches?
From: Josef Wolf @ 2012-11-06 20:18 UTC (permalink / raw)
To: git
Hello,
I know, I should never rebase published branches. But...
I frequently work on different computers and would like to share my private
branches across them. When done and the feature is in a good shape, I'd like
to rebase to clean up history before I make it available to other people.
I guess rebasing such branches would be OK as long as I can reliably remember
to delete those branches on _all_ the clones I ever created.
But waht if I ever make a mistake? How would one recover from such rebase
disasters? Anybody knows a good description how such a recover would be done?
^ permalink raw reply
* Re: Workflow for templates?
From: Josef Wolf @ 2012-11-06 19:50 UTC (permalink / raw)
To: git
In-Reply-To: <20121031104403.GC28437@raven.wolf.lan>
No suggestions on this one?
On Wed, Oct 31, 2012 at 11:44:04AM +0100, Josef Wolf wrote:
> I am somewhat unsure whether it would work this way. After all, there seems to
> be an unbreakable rule with git: never rebase published branches.
>
> Thus, once I have published my work to other people who also need to work on
> the same localizations as I do, I have no longer the option of rebasing to get
> rid of the localizations and put the generic template stuff for upstream.
>
> I guess, my concern is because I have not yet fully understood the problems of
> rebasing, and how to recover from them.
>
> Maybe I should try to explain the problem in terms of repository
> hierarchy. Let's assume, there is this hierarchy of repositories:
>
> upstream: central repository, containing the generic template
>
> foo-site: repository for site foo. Here we have localizations for a specific
> administrative entity named foo (say, google).
> This is where clones for production are made from, and production
> boxes pull from here to be kept up-to-date.
>
> foo-prodA: A clone of foo-site, put in production and pulling from a specific
> branch on foo-site to receive released, blessed updates.
> foo-prodB: Similar to foo-prodA, but on another box.
>
> foo-devA: A clone of foo-site to make development, releases, and whatever for
> foo.
> foo-devB: One more clone of foo-site, Developer B is working here.
>
> Then, we might have more administrative entities: bar-site, bar-prodA,
> bar-prodB, bar-devA, bar-devB, for example. This might be Microsoft, for
> example.
>
> Further, foo-devA might be the same person as bar-devA.
>
> So when foo-devA pulls from foo-devB, then foo-devB will create problems when
> he rebases after that pull.
>
> I think I have some kind of misunderstanding here, but I just can't figure
> what it is.
>
>
> Maybe I should try to explain the problem in yet other words:
>
> What I am trying to achieve, is to extend the workflow from development to
> deployment across multiple administrative entities. As a picture:
>
> upstream (templates only).
> ^
> |
> v
> development (configured, might contain experimental changes)
> ^
> |
> v
> deployment (configured)
>
> This workflow should not stop at administrative borders. Just replace foo by
> google and bar by Microsoft to get an idea of what I am trying to achieve.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: git-p4 clone @all error
From: Vitor Antunes @ 2012-11-06 18:35 UTC (permalink / raw)
To: git
In-Reply-To: <1352211607674-7570631.post@n2.nabble.com>
Arthur <a.foulon <at> amesys.fr> writes:
>
> In ~/.gitconfig i've :
>
> [user]
> name = Arthur
> email = a.xxxxx <at> xxxxx.fr
> [git-p4]
> branchList = MAINLINE:DEV_DATA
> branchList = MAINLINE:RELEASE_1.0
> branchList = MAINLINE:RELEASE_1.0.0
>
> it's ok ?
> So :
>
> /# git config git-p4.branchList
> MAINLINE:DEV_DATA
> error: More than one value for the key git-p4.branchlist:
> MAINLINE:RELEASE_1.0
> error: More than one value for the key git-p4.branchlist:
> MAINLINE:RELEASE_1.0.0/
You need to run "git config --get-all git-p4.branchList" to avoid those
warnings.
How does "git p4 clone //depot@all" behave with these options?
Vitor
P.S. - Please keep me in Cc:
^ permalink raw reply
* Re: [PATCH] push/pull: adjust missing upstream help text to changed interface
From: Junio C Hamano @ 2012-11-06 14:45 UTC (permalink / raw)
To: Michael J Gruber, git; +Cc: Jeroen van der Ham, Jeff King
In-Reply-To: <bd710e422cb8ca0cec4cf52ea3c9ddb284d6c60d.1352197626.git.git@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> wrote:
>Yes, I'm in low hanging fruits mood.
>
>Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
It is called tying loose ends, and is very important. Very much appreciated.
^ permalink raw reply
* Re: [PATCH 0/5] Use string_lists when processing notes
From: Johan Herland @ 2012-11-06 14:20 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Git mailing list
In-Reply-To: <5098C29A.4010901@alum.mit.edu>
On Tue, Nov 6, 2012 at 8:56 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> On 11/04/2012 10:05 PM, Johan Herland wrote:
>> On Sun, Nov 4, 2012 at 8:07 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>>> This simplifies the code. Also, sort lines all at once (O(N lg N))
>>> rather than insertion sorting as lines are processed (O(N^2)) and fix
>>> the handling of empty values in GIT_NOTES_DISPLAY_REF and
>>> GIT_NOTES_REWRITE_REF.
>>>
>>> Michael Haggerty (5):
>>> string_list: add a function string_list_remove_empty_items()
>>> Initialize sort_uniq_list using named constant
>>> combine_notes_cat_sort_uniq(): sort and dedup lines all at once
>>> notes: fix handling of colon-separated values
>>> string_list_add_refs_from_colon_sep(): use string_list_split()
>>
>> Series looks good to me.
>>
>> Acked-by: Johan Herland <johan@herland.net>
>
> Thanks for reviewing the series.
>
> Was it intentional that you didn't CC the mailing list?
No, not at all. Sorry.
Here we go again, with the appropriate CC:
Acked-by: Johan Herland <johan@herland.net>
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: git-p4 clone @all error
From: Arthur @ 2012-11-06 14:20 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20121106T135442-279@post.gmane.org>
In ~/.gitconfig i've :
[user]
name = Arthur
email = a.xxxxx@xxxxx.fr
[git-p4]
branchList = MAINLINE:DEV_DATA
branchList = MAINLINE:RELEASE_1.0
branchList = MAINLINE:RELEASE_1.0.0
it's ok ?
So :
/# git config git-p4.branchList
MAINLINE:DEV_DATA
error: More than one value for the key git-p4.branchlist:
MAINLINE:RELEASE_1.0
error: More than one value for the key git-p4.branchlist:
MAINLINE:RELEASE_1.0.0/
--
View this message in context: http://git.661346.n2.nabble.com/git-p4-clone-all-error-tp7570219p7570631.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: git-p4 clone @all error
From: Arthur @ 2012-11-06 14:03 UTC (permalink / raw)
To: git
In-Reply-To: <1352192140569-7570622.post@n2.nabble.com>
root@Srv-git:/home/arthur/projets_git# git config git-p4.branchList
main:MAINLINE
error: More than one value for the key git-p4.branchlist: MAINLINE:DEV_DATA
error: More than one value for the key git-p4.branchlist:
MAINLINE:RELEASE_1.0
error: More than one value for the key git-p4.branchlist:
MAINLINE:RELEASE_1.0.0
--
View this message in context: http://git.661346.n2.nabble.com/git-p4-clone-all-error-tp7570219p7570630.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: git-p4 clone @all error
From: Vitor Antunes @ 2012-11-06 13:54 UTC (permalink / raw)
To: git
In-Reply-To: <1352192140569-7570622.post@n2.nabble.com>
Arthur <a.foulon <at> amesys.fr> writes:
>
> Thanks for your support,
>
> If i get latest révision on Perforce i have this errors :
>
> / 590 errors reported
> Librarian checkout
> depot/mainline/02_subsystem/10_arinc_429/00_cots/01_bsp_aim/original
> files/api429decryption.txt failed.
> open for read:
> depot/mainline/02_subsystem/10_arinc_429/00_cots/01_bsp_aim/original
> files/api429decryption.txt,v: Le fichier spcifi est introuvable.
> Librarian checkout
> depot/mainline/02_subsystem/10_arinc_429/00_cots/01_bsp_aim/original
> files/api429linuxrelnotes.pdf failed.
> open for read:
> depot/mainline/02_subsystem/10_arinc_429/00_cots/01_bsp_aim/original
> files/api429linuxrelnotes.pdf,d\1.1150: Le chemin d'accs spcifi est
> introuvable.
> Librarian checkout
> depot/mainline/02_subsystem/10_arinc_429/00_cots/01_bsp_aim/original
> files/lien vers readme.txt failed.
> .../
>
> Perforce can't find the files because they were removed. (option
> obliterate...)
> So the error on the Perforce clone may come from this.
To be honest, I don't know how git-p4 behaves when obliterate is used.
> How i can show git-p4.branchList ?
>
> My depot structure :
>
> MAINLINE
> DEV_DATA
> RELEASE_1.0
> RELEASE_1.0.0
>
This tells me you did not setup the branchList configuration. In your
~/.gitconfig please add the following:
[git-p4]
branchList = DEV_DATA:RELEASE_1.0
branchList = DEV_DATA:RELEASE_1.0.0
This assumes that the RELEASE branches are integrated from DEV_DATA.
After the import is successful you can move the [git-p4] from
~/.gitconfig to .git/config of the git repository.
Please make sure you keep in CC, because I'm not subscribed to the
mailing list.
Vitor
^ permalink raw reply
* Re: [PATCH 14/13] wildmatch: fix tests that fail on Windows due to path mangling
From: Nguyen Thai Ngoc Duy @ 2012-11-06 12:47 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano
In-Reply-To: <5096D76F.5090907@kdbg.org>
On Mon, Nov 5, 2012 at 4:00 AM, Johannes Sixt <j6t@kdbg.org> wrote:
> Patterns beginning with a slash are converted to Windows paths before
> test-wildmatch gets to see them. Use a different first character.
Or we could prepend the paths with something, which is then cut out by
test-wildmatch. Not sure if it's intuitive to look at the tests
though.
> After this change, there are still 3 failing tests that are in connection
> with [[:xdigit:]]. Don't know, yet, what's going on there.
the wildmatch tests or fnmatch ones?
--
Duy
^ permalink raw reply
* Re: Bug: write-tree corrupts intent-to-add index state
From: Nguyen Thai Ngoc Duy @ 2012-11-06 12:37 UTC (permalink / raw)
To: Jonathon Mah; +Cc: git@vger.kernel.org
In-Reply-To: <3E62F933-76CD-4578-8684-21444EAA454F@JonathonMah.com>
On Tue, Nov 06, 2012 at 12:53:27AM -0800, Jonathon Mah wrote:
> It appears the index forgot that those files were new. So not only
> has the intent-to-add status been lost, but git status shows a file
> existing in neither HEAD nor the index as not-new-but-modified.
>
> Tracing through it, I narrowed it down to git write-tree affecting
> the index state. As far as I can tell, it's incorrect for that
> command to change the index. I'm now out of my (shallow) depth in
> the git codebase, so I'm throwing it out there for someone to tackle
> (hopefully). I've attached a failing test case.
I played with your test a bit and found that if we skip the commit
step, the bug disappears. I checked and believe that i-t-a flag in
index is preserved, which leaves cache-tree as the culprit. If
cache-tree is (incorrectly) valid, diff operations won't bother
checking index.
We used to not allow writing tree with i-t-a entries present. Then we
allowed it, but forgot that we need to invalidate any paths that
contain i-t-a entries, otherwise cache-tree won't truly reflect
index.
The below patch seems to do the trick, but I'd rather do the
invalidation inside update_one() so we don't need to traverse over the
index again. I haven't succesfully put cache-tree.c back in my head
again to make it happen. Anybody is welcome to step up, or I'll finish
it this weekend.
-- 8< --
diff --git a/cache-tree.c b/cache-tree.c
index 28ed657..30a8018 100644
--- a/cache-tree.c
+++ b/cache-tree.c
@@ -381,6 +381,9 @@ int cache_tree_update(struct cache_tree *it,
i = update_one(it, cache, entries, "", 0, flags);
if (i < 0)
return i;
+ for (i = 0; i < entries; i++)
+ if (cache[i]->ce_flags & CE_INTENT_TO_ADD)
+ cache_tree_invalidate_path(it, cache[i]->name);
return 0;
}
diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh
index ec35409..3ddbd89 100755
--- a/t/t2203-add-intent.sh
+++ b/t/t2203-add-intent.sh
@@ -62,5 +62,25 @@ test_expect_success 'can "commit -a" with an i-t-a entry' '
git commit -a -m all
'
+test_expect_success 'cache-tree invalidates i-t-a paths' '
+ git reset --hard &&
+ mkdir dir &&
+ : >dir/foo &&
+ git add dir/foo &&
+ git commit -m foo &&
+
+ : >dir/bar &&
+ git add -N dir/bar &&
+ git diff --cached --name-only >actual &&
+ echo dir/bar >expect &&
+ test_cmp expect actual &&
+
+ git write-tree >/dev/null &&
+
+ git diff --cached --name-only >actual &&
+ echo dir/bar >expect &&
+ test_cmp expect actual
+'
+
test_done
-- 8< --
^ permalink raw reply related
* [PATCH] push/pull: adjust missing upstream help text to changed interface
From: Michael J Gruber @ 2012-11-06 10:29 UTC (permalink / raw)
To: git; +Cc: Jeroen van der Ham, Jeff King
In-Reply-To: <00F68AED-5D59-44F2-B0F1-E541881BC2CB@uva.nl>
In case of a missing upstream, the git-parse-remote script suggests:
If you wish to set tracking information for this branch you can do so
with:
git branch --set-upstream nsiv2 origin/<branch>
But --set-upstream is deprectated. Change the suggestion to:
git branch --set-upstream-to=origin/<branch> nsiv2
Reported-by: Jeroen van der Ham <vdham@uva.nl>
---
Yes, I'm in low hanging fruits mood.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
git-parse-remote.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 484b2e6..0e87e09 100644
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -80,7 +80,7 @@ See git-${cmd}(1) for details
If you wish to set tracking information for this branch you can do so with:
- git branch --set-upstream ${branch_name#refs/heads/} $remote/<branch>
+ git branch --set-upstream-to=$remote/<branch> ${branch_name#refs/heads/}
"
fi
exit 1
--
1.8.0.226.gba44ac5
^ permalink raw reply related
* Deprecated help message
From: Jeroen van der Ham @ 2012-11-06 9:44 UTC (permalink / raw)
To: git
Hi,
It seems I hit a deprecated help message:
% git pull
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details
git pull <remote> <branch>
If you wish to set tracking information for this branch you can do so with:
git branch --set-upstream nsiv2 origin/<branch>
% git branch --set-upstream nsiv2 origin/nsiv2
The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to
Branch nsiv2 set up to track remote branch nsiv2 from origin.
Jeroen.
^ 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