* 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
* Bug: write-tree corrupts intent-to-add index state
From: Jonathon Mah @ 2012-11-06 8:53 UTC (permalink / raw)
To: git@vger.kernel.org
Hi revisionaries,
I came across what appears to be a bug while working today. I had several changes, both staged and unstaged, and two files that I had marked with intent-to-add (git add -N).
$ git status -sb
## Library-3.x...origin/Library-3.x [ahead 4]
M Library/LIRootSource.m
M Library/Library.xcodeproj/project.pbxproj
[...]
M Library/SceneKit/LISceneKitBookshelfScene.m
AM Library/SceneKit/LISceneKitDisplayedMediumProxy.h
AM Library/SceneKit/LISceneKitDisplayedMediumProxy.m
(The last two files were added with -N.) I then attempted to stash my work, but that failed:
$ git stash -k
error: Entry 'Library/SceneKit/LISceneKitDisplayedMediumProxy.h' not uptodate. Cannot merge.
Cannot save the current worktree state
Re-checking the status showed that the intent-to-add files were now simply modified, yet they did not appear in git ls-tree -r HEAD.
$ git status -sb
## Library-3.x...origin/Library-3.x [ahead 4]
M Library/LIRootSource.m
M Library/Library.xcodeproj/project.pbxproj
[...]
M Library/SceneKit/LISceneKitBookshelfScene.m
M Library/SceneKit/LISceneKitDisplayedMediumProxy.h
M Library/SceneKit/LISceneKitDisplayedMediumProxy.m
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.
Additional notes for bug hunters:
- I've only seen files in already-existing subdirectories lose intent-to-add status, whereas marking a file in the top-level as i-t-a is preserved during write-tree.
- The 'git ls-files -s --debug' output doesn't change across the write-tree:
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 dir/baz
ctime: 0:0
mtime: 0:0
dev: 0 ino: 0
uid: 0 gid: 0
size: 0 flags: 20004000
---
t/t2203-add-intent.sh | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh
index ec35409..fcc67c0 100755
--- a/t/t2203-add-intent.sh
+++ b/t/t2203-add-intent.sh
@@ -62,5 +62,27 @@ test_expect_success 'can "commit -a" with an i-t-a entry' '
git commit -a -m all
'
+test_expect_success 'i-t-a status unaffected by write-tree' '
+ git reset --hard &&
+ mkdir dir &&
+ echo frotz >dir/bar &&
+ git add dir &&
+ git commit -m "establish dir" &&
+ echo fizfaz >foo &&
+ echo fragz >dir/baz &&
+ git add rezrov &&
+ git add -N foo &&
+ git add -N dir/baz &&
+ cat >expect <<-\EOF &&
+ AM dir/baz
+ AM foo
+ EOF
+ git status --untracked-files=no --porcelain >actual &&
+ test_cmp actual expect &&
+ git write-tree &&
+ git status --untracked-files=no --porcelain >actual &&
+ test_cmp actual expect
+'
+
test_done
--
1.8.0
Jonathon Mah
me@JonathonMah.com
^ permalink raw reply related
* Re: git-p4 clone @all error
From: Arthur @ 2012-11-06 8:55 UTC (permalink / raw)
To: git
In-Reply-To: <20121106002515.5b7eba50@fenix.utopia.dhis.org>
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.
How i can show git-p4.branchList ?
My depot structure :
MAINLINE
DEV_DATA
RELEASE_1.0
RELEASE_1.0.0
--
View this message in context: http://git.661346.n2.nabble.com/git-p4-clone-all-error-tp7570219p7570622.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 1/4] strbuf_split_buf(): use ALLOC_GROW()
From: Michael Haggerty @ 2012-11-06 7:54 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20121104114101.GA336@sigill.intra.peff.net>
On 11/04/2012 12:41 PM, Jeff King wrote:
> On Sun, Nov 04, 2012 at 07:46:51AM +0100, Michael Haggerty wrote:
>
>> Use ALLOC_GROW() rather than inline code to manage memory in
>> strbuf_split_buf(). Rename "pos" to "nr" because it better describes
>> the use of the variable and it better conforms to the "ALLOC_GROW"
>> idiom.
>
> I suspect this was not used originally because ALLOC_GROW relies on
> alloc_nr, which does fast growth early on. At (x+16)*3/2, we end up with
> 24 slots for the first allocation. We are typically splitting 1 or 2
> values.
>
> It probably doesn't make a big difference in practice, though, as we're
> talking about wasting less than 200 bytes on a 64-bit platform, and we
> do not tend to keep large numbers of split lists around.
I did a little bit of archeology, and found out that
* ALLOC_GROW() did indeed exist when this code was developed, so it
*could have* been used.
* OTOH, I didn't find any indication on the mailing list that the
choice not to use ALLOC_GROW() was a conscious decision.
So history doesn't give us much guidance.
If the size of the initial allocation is a concern, then I would suggest
adding a macro like ALLOC_SET_SIZE(ary,nr,alloc) that could be called to
initialize the size to some number less than 24. Such a macro might be
useful elsewhere, too. It wouldn't, of course, slow the growth rate
*after* the first allocation.
FWIW, the "max" parameter of strbuf_split*() is only used in one place,
though strbuf_split*() is used in some other places where not too many
substrings would be expected.
I am working on some patch series that will eliminate even more uses of
strbuf_split*(), so I won't work more on optimizing its resource usage
unless somebody gives me a stronger nudge.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Support for a series of patches, i.e. patchset or changeset?
From: Johannes Sixt @ 2012-11-06 7:44 UTC (permalink / raw)
To: Eric Miao; +Cc: Michael J Gruber, git
In-Reply-To: <CAMPhdO_yK02r4c5tTZxFGikmcPiG4G=PMzsPrYOtKCR51Ep0sw@mail.gmail.com>
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?
-- Hannes
^ permalink raw reply
* Re: [PATCH v4 6/8] longest_ancestor_length(): require prefix list entries to be normalized
From: Michael Haggerty @ 2012-11-06 7:34 UTC (permalink / raw)
To: Ramsay Jones
Cc: Jeff King, Junio C Hamano, Jiang Xin, Lea Wiemann, Johannes Sixt,
git, David Aguilar
In-Reply-To: <50901B31.7000402@ramsay1.demon.co.uk>
On 10/30/2012 07:23 PM, Ramsay Jones wrote:
> [...]
> Just to be clear, this is true for the MinGW port to Windows, but *not*
> the cygwin port.
>
> [...]
>
> ditto
Thanks for clarifying these points. It seems like this patch series is
not going to be usable (because of fears that it might cause performance
degradation in some as-yet-unexplained scenarios), but if that situation
seems to change then I will incorporate your corrections.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Support for a series of patches, i.e. patchset or changeset?
From: Eric Miao @ 2012-11-06 6:56 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Michael J Gruber, git
In-Reply-To: <5098B09B.7060501@viscovery.net>
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:
>> On Mon, Nov 5, 2012 at 10:40 PM, Michael J Gruber
>> <git@drmicha.warpmail.net> wrote:
>>> Eric Miao venit, vidit, dixit 05.11.2012 15:12:
>>>> The problem is, most cases we have no idea of the base rev1, and commit rev2
>>>> which it's leading up to. E.g. for a single patch which is between
>>>> commit rev1..rev2,
>>>> how do we find out rev1 and rev2.
>>
>> 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?
But this still looks like be inferred basing on a branch head, and I'm
afraid this may not be applicable in every case.
>
> -- Hannes
^ permalink raw reply
* Re: Support for a series of patches, i.e. patchset or changeset?
From: Johannes Sixt @ 2012-11-06 6:39 UTC (permalink / raw)
To: Eric Miao; +Cc: Michael J Gruber, git
In-Reply-To: <CAMPhdO-Z3E352KbTvnrxJqCecAUGfHCwOoFRUKzObh35uLnrSw@mail.gmail.com>
Am 11/6/2012 1:58, schrieb Eric Miao:
> On Mon, Nov 5, 2012 at 10:40 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Eric Miao venit, vidit, dixit 05.11.2012 15:12:
>>> The problem is, most cases we have no idea of the base rev1, and commit rev2
>>> which it's leading up to. E.g. for a single patch which is between
>>> commit rev1..rev2,
>>> how do we find out rev1 and rev2.
>
> 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.
-- Hannes
^ permalink raw reply
* Re: Support for a series of patches, i.e. patchset or changeset?
From: Eric Miao @ 2012-11-06 0:58 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <5097CFCB.7090506@drmicha.warpmail.net>
On Mon, Nov 5, 2012 at 10:40 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Eric Miao venit, vidit, dixit 05.11.2012 15:12:
>> The problem is, most cases we have no idea of the base rev1, and commit rev2
>> which it's leading up to. E.g. for a single patch which is between
>> commit rev1..rev2,
>> how do we find out rev1 and rev2.
>
> So, then the question is: What do you know/have? Is your patch the
> output of "git format-patch", "git diff", or just some sort of diff
> without any git information?
That doesn't matter, all the info can be obtained from the SHA1 id, the
question is: do we have a mechanism in git (or hopefully we could add)
to record the patchset or series the patch belongs to, without people to
guess heuristically.
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?
^ permalink raw reply
* Re: git compilation problem
From: Konstantin Khomoutov @ 2012-11-06 0:53 UTC (permalink / raw)
To: git-users-/JYPxA39Uh5TLH3MbocFFw; +Cc: git-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <f4b73b42-0c5e-40ad-9f84-e4d8d00a226a-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
On Mon, Nov 05, 2012 at 09:21:13AM -0800, Mathieu Dutour wrote:
First, note that this list is a support channel for Git newbies, and
your question appears to be more about Git source code itself so I'd say
it better fits the main Git list which is git at vger.kernel.org.
I Cc'ed this my response here in the hope someone with the platform
similar to yours might chime in; so please keep the Cc list in your
responses.
> I tried to install git on an IBM power 6 computer and I had the following
> problem when doing "gmake install"
This doesn't sound quite descriptive. From what I gather from the
Internet, IBM POWER 6 is a CPU brand, targeted at mainframes. I vaguely
recall IBM mainframes typically run their own OS (z/OS?) but have
extensive support for virtualization so I recall I read somewhere it's
customary to run, say, a virtualized Linux-based OS on it.
Since what matters here is a *software* platform, please be (way) more
precise about this.
> ./configure[6213]: syntax error at line 6367 : `;' unexpected
"configure" is just a shell script usually generated by the "autoconf"
program from a template file named "configure.in".
"configure" is meant to be über-portable, but it assumes your /bin/sh is
a shell implementing the command language defined by POSIX, plus a
standard set of text-processing tools (such as sed and grep) is
available.
I can make a guess that whatever is available as /bin/sh in your system
might not quite fit the expectations of "configure".
I envision two ways to fix this:
1) Install autoconf and run it to regenerate the configure script;
then try the compilation again.
2) Try to force configure using a different shell, if available.
GNU bash should cut it, ash and dash [1] too.
In either case note that there isn't any indication that that syntax
error actually made the build process to fail; the only failing error
in the output you quoted is that of the `install` command which runs
after the compilation is done to install things (obviously).
By this I mean, if you will be able to fix that `install` error it might
turn out you could ignore the configure error whatsoever.
> gmake[2]: `GIT-VERSION-FILE' is up to date.
> GEN git-instaweb
> SUBDIR git-gui
> SUBDIR gitk-git
> gmake[1]: Nothing to be done for `all'.
> SUBDIR perl
> SUBDIR git_remote_helpers
> SUBDIR templates
> install -d -m 755 '/home/ar69ovim/opt/git-1.8.0/bin'
> /usr/bin/getopt: Not a recognized flag: d
> Usage: install [-c DirectoryA] [-f DirectoryB] [-i] [-m] [-M Mode] [-O
> Owner]
> [-G Group] [-S] [-n DirectoryC] [-o] [-s] File [DirectoryX
> ...]
Supposedly Git makefiles expect the `install` program to support the
"-d" command line option. On my Linux system with `install` provided by
GNU coreutils [2], the "-d" command line option of this tool is used to
create the whole directory hierarchy according to the argument passed to
that option. Obviously your `install` does not support this option.
Moreover, from the error output it follows, that your `install` is
implemented as a shell script which calls /usr/bin/getopt to parse its
command-line options.
Again, I can see several ways to fix that:
1) Patch Git makefile(s) to use some other means to create directory
hierarchies. For instance, some versions of `mkdir` support the "-p"
command line option to do this. You could combine `mkdir -p` with
`chmod 755` to do what `install -d -m 755` would do.
2) (Somehow) get GNU coreutils and make Git makefiles see
/usr/bin/install provided by this package.
3) Patch your `install` to support "-d".
> gmake: *** [install] Error 2
That's what makes the whole thing fail.
1. http://en.wikipedia.org/wiki/Debian_Almquist_shell
2. http://gnu.org/software/coreutils
--
^ 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