Re: git-bundle rev handling and de-duping
"Philip Oakley" writes: >> # two branches point at the same object >> git branch foo master >> >> # the other side already has master. Let's send them foo. >> # this will fail because the bundle is empty. That's mildly >> # annoying because we really want to tell them "hey, update >> # your foo branch". But at least we get an error. >> git bundle create tmp.bundle foo ^master > > Isn't this kindof what happens as an issue when we want the right HEAD > to be included explicitly in a bundle. Though What we are discussing here is "we tell from the command line where the histories end, but do we correctly record all these end points as fetchable refs in the resulting bundle?" It does not have anything to do with "bundle that does not record its HEAD cannot be cloned", which happens when you do not mention HEAD when creating the bundle in the first place, which is a totally different thing. > http://thread.gmane.org/gmane.comp.version-control.git/234053 suggests > its more complicated than that. The main topic of discussion does not have much to what bundle records and what a reader of a bundle guesses. It is about what goes on the wire and mention of bundle was just a tangent brought up by those who do not know what was being discussed, I think. I think the right fix to the "git bundle" issue is to make it easier on the "git bundle create" side to have the resulting bundle record its HEAD, even when the user did not mention HEAD on the command line. For example, when there is only one end point, e.g. "git bundle create x next", record refs/heads/next _and_ HEAD pointing at the same commit, because there is no other seneible choice. "git bundle create y master next" may record master, next and HEAD while HEAD is likely pointing at the same commit as master (because 'master' is special). Or we could give a warning and even go interactive to ask which ref to record as HEAD. But the above three paragraphs are tangent so I'd stop here. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] core.filemode may need manual action
core.filemode is set automatically when a repo is created. But when a repo is exported via CIFS or cygwin is mixed with Git for Windows or Eclipse core.filemode may better be set manually to false. Update and improve the documentation Helped-by: Junio C Hamano Signed-off-by: Torsten Bögershausen --- Thanks for careful reading. Changes since V1: - The '+' at an otherwise empty line generates an empty line in html, so s/^$/+/ - Changed msygit into Git for Windows - Mention Eclipse - Minor changes in the wording, remove one comma - Remove the "The default is true, except " This line is maybe confusing. "The default is true" is not wrong as such, we have int trust_executable_bit = 1; But: these days most repos have core.filemode defined, so describing this default gives not much new information to the user. (please correct me if that is wrong) Especially the "except" is not really helpful, because the default is always true, and git.git will always probe. Any thoughts ? Now we mention the probing 2 times, I am not 100% happy with this, please see V2B Another thing is that both Git for Windows and Eclipse can not handle the filemode, and should silently ignore the flag, which is a different patch. Documentation/config.txt | 23 +++ 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 04a1e2f..959dc11 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -204,12 +204,27 @@ advice.*:: -- core.fileMode:: - If false, the executable bit differences between the index and - the working tree are ignored; useful on broken filesystems like FAT. + Tells Git if the executable bit of files in the working tree + is to be honored. ++ + Some filesystems lose the executable bit when a file that is + marked as executable is checked out, or checks out an + non-executable file with executable bit on. "git init" and + "git clone" probe the filesystem to see if it records + executable bit correctly when they create a new repository + and this variable is automatically set as necessary. ++ + A repository, however, may be on a filesystem that handles + the filemode correctly, and this variable is set to 'true' + when created, but later may be made accessible from another + environment that loses the filemode (e.g. exporting ext4 via + CIFS mount, visiting a Cygwin created repository with + Git for Windows or Eclipse). + In such a case it may be necessary to set this variable to 'false'. See linkgit:git-update-index[1]. + -The default is true, except linkgit:git-clone[1] or linkgit:git-init[1] -will probe and set core.fileMode false if appropriate when the +linkgit:git-clone[1] or linkgit:git-init[1] +will probe and set core.fileMode to true or false when the repository is created. core.ignorecase:: -- 2.1.0.rc2.210.g636bceb -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2B] core.filemode may need manual action
core.filemode is set automatically when a repo is created. But when a repo is exported via CIFS or cygwin is mixed with Git for Windows or Eclipse core.filemode may better be set manually to false. Update and improve the documentation Helped-by: Junio C Hamano Signed-off-by: Torsten Bögershausen --- Does this makes more sence ? Documentation/config.txt | 23 ++- 1 file changed, 18 insertions(+), 5 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 04a1e2f..3127e5d 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -204,13 +204,26 @@ advice.*:: -- core.fileMode:: - If false, the executable bit differences between the index and - the working tree are ignored; useful on broken filesystems like FAT. + Tells Git if the executable bit of files in the working tree + is to be honored. ++ + Some filesystems lose the executable bit when a file that is + marked as executable is checked out, or checks out an + non-executable file with executable bit on. + linkgit:git-clone[1] or linkgit:git-init[1] probe the filesystem + to see if it handles the executable bit correctly + and this variable is automatically set as necessary. ++ + A repository, however, may be on a filesystem that handles + the filemode correctly, and this variable is set to 'true' + when created, but later may be made accessible from another + environment that loses the filemode (e.g. exporting ext4 via + CIFS mount, visiting a Cygwin created repository with + Git for Windows or Eclipse). + In such a case it may be necessary to set this variable to 'false'. See linkgit:git-update-index[1]. + -The default is true, except linkgit:git-clone[1] or linkgit:git-init[1] -will probe and set core.fileMode false if appropriate when the -repository is created. +The default is true (when core.filemode is not specified in the config file). core.ignorecase:: If true, this option enables various workarounds to enable -- 2.1.0.rc2.210.g636bceb -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] t1304: Set LOGNAME even if USER is unset or null
Avoid:
# ./t1304-default-acl.sh
ok 1 - checking for a working acl setup
ok 2 - Setup test repo
not ok 3 - Objects creation does not break ACLs with restrictive umask
#
# # SHA1 for empty blob
# check_perms_and_acl
.git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391
#
not ok 4 - git gc does not break ACLs with restrictive umask
#
# git gc &&
# check_perms_and_acl .git/objects/pack/*.pack
#
# failed 2 among 4 test(s)
1..4
on systems where USER isn't set. It's usually set by the login
process, but it isn't set when launching some Docker images. For
example:
$ docker run --rm debian env
HOME=/
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=b2dfdfe797ed
'id -u -n' has been in POSIX from Issue 2 through 2013 [1], so I don't
expect compatibility issues.
[1]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/id.html
Signed-off-by: W. Trevor King
---
The patch is based on the current maint branch.
Previous LOGNAME discussion:
* Michael Gruber on 2011-05-06 suggesting a discussing a whoami
fallback [1] (but whoami isn't POSIX).
* René Scharfe on 2011-10-14 suggesting USER as a fallback for
LOGNAME [2].
* Matthieu Moy on 2012-09-17 suggesting dropping $LOGNAME in
favor of numerical user IDs 'id -u' for a system with multiple
usernames sharing the same user ID [3].
Obviously, you can work around the problem with:
# USER=$(id -u -n) ./t1304-default-acl.sh
so the question is really "Are empty-USER systems worth supporting out
of the box?".
Cheers,
Trevor
[1]: http://thread.gmane.org/gmane.comp.version-control.git/172883/focus=172961
[2]: http://thread.gmane.org/gmane.comp.version-control.git/183586
[3]: http://thread.gmane.org/gmane.comp.version-control.git/205690/focus=205703
t/t1304-default-acl.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t1304-default-acl.sh b/t/t1304-default-acl.sh
index 79045ab..f5422f1 100755
--- a/t/t1304-default-acl.sh
+++ b/t/t1304-default-acl.sh
@@ -26,7 +26,7 @@ test_expect_success 'checking for a working acl setup' '
if test -z "$LOGNAME"
then
- LOGNAME=$USER
+ LOGNAME="${USER:-$(id -u -n)}"
fi
check_perms_and_acl () {
--
2.1.0.60.g85f0837
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
git pull freeze
Good evening, I am having difficulties with "git pull" command. Couple days ago it worked perfectly, no problem. Now this command just runs, and does "nothing" without any output. I discovered that it is actually doing something and within one or two hours it finishes successfully. But before it took few seconds, not even a minute. Other commands like push, fetch or merge are running normally. I observe the same behaviour with command stash, but I am not sure if pull is using this one. I am using git version 1. 9. 4 from windows exe reviewed on 20140929. Windows 8.1. Through cmd line. I reinstalled program many times, cleared temporary directories, cleared records in registers, ran with administrator rights. The same (freeze) if I try to use my cygwin unix git. On my unix virtual machine - no problem, on nonlocal unix machine also no problem. Do you have something to suggest? The main problem is that there is no output so I can hardly define the problem. I can provide you with more information about my system if needed. Best regards Kryštof Tulinger -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-bundle rev handling and de-duping
From: "Jeff King" [subject tweaked as we have veered quite far off the original, and this might get more attention from interested people] On Thu, Oct 16, 2014 at 10:39:54AM -0700, Junio C Hamano wrote: 2. We use object_array_remove_duplicates() to de-dup "git bundle create x master master", which came from b2a6d1c6 (bundle: allow the same ref to be given more than once, 2009-01-17), which is still the sole caller of the function, and I think this is bogus. Comparing .name would not de-dup "git bundle create x master refs/heads/master". Hmm. We also doesn't respect the UNINTERESTING flag, so it will dedup "foo" and "^foo" into a single entry. I _think_ this doesn't have any bad side effects, because they are equivalent (i.e., the flag is carried on the object, not the pending entry). I would expect this: git bundle create ... foo ^foo to barf (and it does) because the bundle is empty. But with this: git bundle create ... another-ref foo ^foo I would expect the resulting bundle to contain the objects from another-ref, but still mention "foo" as an update (we didn't need to send any objects, since presumably the other side already had them). It doesn't, but that is not because of the dedup. It is because we generate the list of refs to send based on the pending list, and we skip all UNINTERESTING objects (we must, because otherwise "^foo" would make an entry). I.e., it is the same "the flag is on the object, not the pending entry" that saved us above now causing its own bug. Obviously the example above is sort of silly, but if you have: # two branches point at the same object git branch foo master # the other side already has master. Let's send them foo. # this will fail because the bundle is empty. That's mildly # annoying because we really want to tell them "hey, update # your foo branch". But at least we get an error. git bundle create tmp.bundle foo ^master Isn't this kindof what happens as an issue when we want the right HEAD to be included explicitly in a bundle. Though ttp://thread.gmane.org/gmane.comp.version-control.git/234053 suggests its more complicated than that. # now the same thing, but we're sending them some other objects. # This one succeeds, but silently omits foo from the bundle! git bundle create tmp.bundle foo another-ref ^master I have a feeling that the list needs to be generated from revs.cmdline, not revs.pending, and the de-duplication needs to happen there (with the ref resolution that you mention). I also have the feeling that fast-export had to deal with this exact same issue. It looks like we use revs.cmdline there. I seem to recall there was some ongoing work in that area, but I stopped paying close attention due to some personality conflicts, and I don't know if all of the issues were ever resolved. I think the right way to fix these two and a half problems is to do the following: - object_array_remove_duplicates() (and contains_name() helper it uses) should be removed from object.c; - create_bundle() in bundle.c should implement a helper that is similar to contains_name() but knows about ref dwimming and use it to call object_array_filter() to replace its call to object_array_remove_duplicates(). Agreed. The loop in create_bundle right after the de-dup does the dwimming. Probably it would be simple to just skip duplicates there using a hashmap or sorted list. I am not doing this myself, and I do not expect either you or Michael to do so, either. I am just writing this down to point out a low hanging fruit to aspiring new contributors (hint, hint). I am also not planning on working on it soon, but now we have hopefully fed plenty of possibilities to anybody who wants to. :) -- Philip -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git-svn performance
Hi,
I'm currently migrating an SVN repository to Git using git-svn (Git
for Windows 1.8.3-preview20130601), and I'm experiencing severe
performance problems with "git svn fetch". Commits to the SVN "trunk"
are fetched very fast (a few seconds or so per SVN revision), but
commits to some branches ("hotfix" branches) are currently taking
about 9 minutes per revision. I fear that the time per these commits
is increasing and that indeed the migration might not be finishable at
all.
For the commits that take such a long time, git-svn always outputs
lots of warnings about ignored SVN cherry-picks, and it tells me it
can't find a revmap for the path being imported. (See [1].)
AFAICS, the offending commits take place on some branches that include
a lot of manually merged ("SVN cherry-picked") revisions. Git-svn
seems to be checking something (though I don't know what) that makes
importing these revisions really slow. And it repeats this for every
revision on these branches with increasing work to do.
Is there anything I can do to speed this up? (I already tried
increasing the --log-window-size to 500, didn't have any effect.)
Thank you, best regards,
Fabian
[1]
M foo/bar/XXX.xml
M foo/bar/YYY.xml
W:svn cherry-pick ignored (/branches/frob:6940-7068) - missing 12
commit(s) (eg abeaece820ceae44ebf2c06011cf43bbcbf4b1ce)
W:svn cherry-pick ignored (/branches/feature:3316-4798,4811,4827) -
missing 10 commit(s) (eg e255fff14ab1e581f21671ca8b36c0747869cf8c)
W:svn cherry-pick ignored
(/hotfixes/ZZZ.159:2131,2133,2145-2146,2148,2169) - missing 10
commit(s) (eg e04b0326c998f0611c18144b3ed8f686d3b52f4c)
W:svn cherry-pick ignored
(/hotfixes/ZZZ.333:4536,4610-4611,4625,4665,4669,4685,4713,4745,4785,4788,4908-4917,4920,4933-4944,4955,5003,5103,5174,5222,5227,
5261,5267,5306,5310,5321,5360,5416,5467,5501,5508,5599-5614,5650-5651,5757,5761-5762,5764,5778-5779,5784,5811,5814,5819,5823,5825,5836-5838,5860,5862,5873,5889,
5910,5924,5948) - missing 137 commit(s) (eg
9daec24cbdf55200d2cdfb0cd6b3f10485e296ac)
C:\Program Files (x86)\Git\bin\perl.exe: *** WFSO timed out
W:svn cherry-pick ignored (/hotfixes/ZZZ.333.39:5696,5847) - missing
84 commit(s) (eg 9daec24cbdf55200d2cdfb0cd6b3f10485e296ac)
W:svn cherry-pick ignored (/hotfixes/AAA:5905,6095) - missing 119
commit(s) (eg 9daec24cbdf55200d2cdfb0cd6b3f10485e296ac)
W:svn cherry-pick ignored (/hotfixes/BBB_1.1:6971) - missing 198
commit(s) (eg 9daec24cbdf55200d2cdfb0cd6b3f10485e296ac)
W:svn cherry-pick ignored
(/hotfixes/CCC:6134,6164,6168,6174,6206,6211,6237,6239,6244-6245,6250,6257,6269,6271,6276,6289-6292,6294,6296,6301-6302,6313,6315-6316,6329,6333,6379,6383,6394,6405,6411,6456,6478,6483,6491,6519,6537,6557)
- missing 194 commit(s) (eg 9daec24cbdf55200d2cdfb0cd6b3f10485e296ac)
W:svn cherry-pick ignored (/hotfixes/DDD:7635) - missing 1 commit(s)
(eg 6a3ba817635eb3a9411a307924dec393311d93be)
W:svn cherry-pick ignored
(/hotfixes/EEE_1.2:7786,7794,7797,7803,7829-7830,7843,7886,7889,7933,7937,7949,7953)
- missing 80 commit(s) (eg e78b1bc68f7a9b041588a39f3fa5e1a61f98942b)
W:svn cherry-pick ignored
(/hotfixes/EEE_1.3:8159,8170,8173-8174,8177,8181-8182,8185,8187,8194-8195,8201,8203,8206,8251,8255,8257,8259-8262,8265,8280,8286,8294,8296,8304-8305,8312,8318,8323,8327,8363,8387-8388,8390,8422-8423,8432,8446,8536-8537,8548-8549,8556,8559,8566,8569,8572,8578,8597-8598,8602,8617,8619,8655,8687,8720)
- missing 104 commit(s) (eg 33febd4591f42a9d871ba330432840917b157f9e)
W:svn cherry-pick ignored
(/hotfixes/EEE_1.4:8766,8768,8770,8777-8779,8795-8796,8802-8809,8812-8814,8816-8817,8820,8823,8825,8827,8831,8836,8841,8845,8848-8852,8854-8855,8866,8868-8869,8871-8873,8875-8878,8880,,8892,8911-8912,8917-8918,8946,8956-8957,8964,8984,8994,9003,9008,9011,9029,9038,9040,9046-9048,9055,9086,9101,9108,9111,9113,9124,9129,9133,9138-9139,9150,9152,9154,9156,9172,9174,9188-9189,9208,9211,9217)
- missing 44 commit(s) (eg 0621fb44de682650d762c707b102bc2472c088f8)
W:svn cherry-pick ignored
(/hotfixes/EEE_1.5:9412,9421,9430,9433-9436,9439,9441,9449,9459,9468,9529,9548,9561,9568,9605-9606,9612,9614,9617,9628,9630-9631,9637,9687,9807)
- missing 41 commit(s) (eg 1bd1a9b72336bf4d3839a00348b7f2a52368c16c)
W:svn cherry-pick ignored
(/trunk:9852-9853,9857,9859,9862,9868,9872,9876,9879,9890,9895,9926-9927,9933,9953,9956,9960-9962)
- missing 60 commit(s) (eg 3322e7ffc6ab49181976d9e94c91a4556951f38a)
Couldn't find revmap for https://the-svn-server/svn/something/trunk/foo
r9963 = 597df48cb830825f9029d1cfdf45df024d7fd3dd (refs/remotes/EEE_1.6)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
__git_ps1_colorize__gitstring() in git_prompt.sh: colors are hardcoded?
Hello,
It seems to me that the colors used to indicate the repo's state in the
prompt are hardcoded although the top comment says otherwise.
>From contrib/completion/git-contrib.sh:
[83]# If you would like a colored hint about the current dirty state, set
# GIT_PS1_SHOWCOLORHINTS to a nonempty value. The colors are based on
# the colored output of "git status -sb" and are available only when
# using __git_ps1 for PROMPT_COMMAND or precmd.
[228]__git_ps1_colorize_gitstring ()
{
if [[ -n ${ZSH_VERSION-} ]]; then
local c_red='%F{red}'
local c_green='%F{green}'
local c_lblue='%F{blue}'
local c_clear='%f'
else
# Using \[ and \] around colors is necessary to prevent
# issues with command line editing/browsing/completion!
local c_red='\[\e[31m\]'
local c_green='\[\e[32m\]'
local c_lblue='\[\e[1;34m\]'
local c_clear='\[\e[0m\]'
fi
local bad_color=$c_red
local ok_color=$c_green
local flags_color="$c_lblue"
local branch_color=""
As expected upon seeing this snippet, the color.status. entries in
the git config file do modify the git status -sb output but don't modify
the colors used in the prompt.
Regards,
Nathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clone: --dissociate option to mark that reference is only temporary
On 2014-10-16 17:26, Marc Branchaud wrote:
I just don't see what difference the --borrow option makes. Consider the two
cases:
With just --reference=/local/pool/linux.git:
1. Set up the alternates file with that path.
x. Fetch object from origin not present in pool
2. Copy gko's refs into refs/remotes/origin/.
3. Set up refs/heads/master to refer to gko's HEAD.
4. Checkout refs/heads/master (uses objects from local pool).
With both that --reference and --borrow=../my/neighbour/linux-hack.git:
1. Set up the alternates file with both paths.
x. Fetch objects from origin not present in either pool
or neighbour repo ("have" pool and neighbour)
2. Copy gko's refs into refs/remotes/origin/.
3. Set up refs/heads/master to refer to gko's HEAD.
4. Checkout refs/heads/master (uses objects from local pool).
5. Disassociate ourselves from the neighbour repo.
which means roughly:
5.1. Remove neighbour repo from alternates
5.2. Fetch required objects from neighbour repo
("want" neighbour, have ???)
It is possible that because of technical limitations --reference and
--borrow / dissociate / --temporary-reference / --object-cache are to be
mutually exclusive.
In both cases the first four actions have no need of the neighbour repo. The
second case's fifth action surgically removes the neighbour as an alternate
object store, and we're left with the same clone we got in the first case.
What was the point?
You are missing fetching object from your list of actions.
It seems that in order to make something like --borrow useful, "git clone"
would somehow need to know which of the neighbour's refs you want to *also*
clone, then copy any unique objects from the neighbour before disassociating
from it.
M.
--
Jakub Narębski
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Stop prepending /usr/bin to hooks PATH, or document it very clearly
On hooks Git automatically prepends to the `PATH` via the `setup_path` function: - `git --exec-path` (`/usr/lib/git-core`) - the directory of `$0` (`/usr/bin`) if you call it with the full path The problem is that the `/usr/bin` breaks "interpreter version manager systems" like RVM, rbenv, virtualenv, etc. since people will write hooks like: #!/usr/bin/env ruby and the `/usr/bin` ruby will get run instead of the managed one (`~/.rvm/some/path/bin). I recommend either: - not adding the `$0` if possible (ideal but backwards incompatible unless a new config is added) - documenting this behavior *very* clearly on `man githooks` - proposing some other mechanism that neatly solves the problem I will try to submit a patch for the desired solution if within my technical capability. Samples of problems this has caused people: - https://github.com/gitlabhq/gitlabhq/issues/8045 - http://stackoverflow.com/questions/9037284/how-can-i-run-a-virtualenv-python-script-as-a-git-pre-commit-hook - http://stackoverflow.com/questions/17515769/why-is-my-ruby-git-script-hook-run-with-the-wrong-path - https://github.com/sstephenson/rbenv/issues/374 - https://github.com/magit/magit/issues/498 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Multiple worktrees vs. submodules fixes
On Thu, Oct 16, 2014 at 12:09 AM, Junio C Hamano wrote: > Hmph. I was hoping that the multiple-work-trees topic was ready for > 'next' by now, but we may want to wait to see how the interaction > with submodule plays out to have another chance of a clean reroll > before it happens. This is a topic with large impact and is quite > intrusive code-wise, even though the intrusive parts are cleanly > done. So we'd want to take more time to unleash it to the general > public than more usual small scale topics, anyway. Originally I wanted to get it merged without submodule support, but I failed to spot the local_repo_env problem and could have caused a regression for submodules. So yeah delaying the series does not sound bad. Not sure about the reroll (i.e. rewriting current patches). I think putting patches on top with explanation is better. But we can keep it in 'pu' and see if we really need to reroll. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
